M1G + Uplink + POTS as backup - doesn't fail over to backup

[Linwood]

I'm trying to more thoroughly test my setup, and wanted to test failover from the Uplink 2500 to a POTS line.  The Uplink is primary, has worked for a couple years just fine, but I realized I never thoroughly tested it.
 
The Uplink 2500 is connected to a M1XSP (the special one) and connected to the M1G.  The Elk stuff is all current firmware.  The Uplink goes to NextAlarm.
 
The Uplink works fine as primary.
 
If I disabled the telephone entry for the Uplink in ElkRP, the POTS line works fine.  Both have been tested with NextAlarm.
 
But I wanted to test a real failure instead, so with Uplink primary and POTS backup, I disconnected the serial cable to the Uplink.
 
I have a rule programmed to announce the lost/restore messages, and cause a 24-hour alarm to go off (and send email).  The rule worked fine, the email went, the announcement went.
 
NextAlarm didn't receive anything.
 
Waited... waited... nothing.  Waited about 5 minutes.
 
Reconnected serial cable, and NextAlarm almost immediately got two alarms, followed by two restores for this supervision zone.  
 
Did it all again, more carefully -- same result.  No POTS line call, but when the Uplink was reconnected the (buffered?) message from the alarm was sent.
 
I am GUESSING that the M1XSP is accepting the message from the M1G, but can't send it, and is holding onto it.  But (again, complete guess) the M1G doesn't fail over because it didn't get an error from the M1XSP.
 
Now why I get two of each recorded at NextAlarm I have no idea.
 
Am I missing a step?   

Telephone 1 = Uplink = type 0= always report via 7=Serial Expander, call attempts = 1
Telephone 2 = POTS = type 1 = Report to this number as backup via 1 = CID, call attempts = 1 (I intend to increase these later)
 
And again, by setting each one separately to disabled and the other to type 0, both Uplink and POTS work, separately.
 
Any ideas? 

 

[Linwood]

On a related note, is there a way to see exactly what is sent out via the various telephone definitions? 
 
I've connected to the ethernet port 2101 and checked the data it displays against the serial protocol, I can see the alarm response information, but I can't see any indication in there are the act of dialing or sending to the serial port or anything.  So I can't really see what's happening with the dialing above.  Is there a way to get more information in that serial port dump?
 
Ps. If anyone hasn't looked at it, all you need is a telnet client (e.g. putty), and connect to port 2101 (if that's open on yours) instead of port 23.  the data just sits and flows down the screen, and it comes out in the M1 RS232 ASCII Protocol (the documentation is on the Elk site).  Looks a bit like this:
 
08RP010035
08RP010035
16XK58202220303140100075
16XK28212220303140100077
17IC000000000000203020075
17IC000000000000203020075
1EAS2000000041111111000000000009
0FEE10060180200DE
1EAS2000000031111111000000003BF5
17IC000000000000001020079
0FEE10000000000EF
1EAS000000001111111100000000000E
16XK58212220303140100074
16XK28222220303140100076
16XK58222220303140100073

 

[Linwood]

I am convinced this is either a bug int he Elk M1G, or I am just really unable to read directions.  I sure hope someone can clarify.  And/or should I ask Elk? 
 
I very carefully tested these scenarios this morning, leaving a long time between events (20 minutes once) to make sure it was not a race condition.
 
Scenario #1:  (disable Uplink by pulling comm cable) 
   Telephone1 = Uplink 2500
   Telephone2 = POTS (as backup)
 
    Result: No transmission to CS until restore comm cable, then both fail and restore reported
 
Scenario #2:  (disable uplink by pulling serial module from bus)
    Telephone1 = Uplink 2500
    Telephone2 = POTS (as backup)
 
    Result: no transmission to CS until restore, then reported restore via cell (did not report failure)
 
Scenario #3: (disable uplink by pulling comm cable)
   Telephone1 = Uplink 2500
   Telephone2 = POTS (NOT as backup, but also to report each time)
 
    Result: transmission to CS over POTS in timely fashion, THEN 
              After restoral of comm cable (much later to be sure) received it again via CELL
 
Scenario #3: (disable POTS by putting in incorrect (own) number, trigger intrusion alarm) 
    Telephone1 = POTS (dial retries = 1)
    Telephone2 = Uplink 2500 as backup
 
    Result: Transmission sent, but VERY slowly (4 minutes 40 seconds after alarm
 
 
 
In other words, I cannot make a POTS line be a backup for the Uplink.  No matter what scenario I try, it will not fail over to the POTS line and dial.
 
I can make the uplink be a backup for the POTS line, but at least in the scenario where there is dial tone but no communication (e.g. wrong number entered), it takes a long time (4+ minutes) to do the fail over even with a dialer retry limited to 1. 
 
I had wanted POTS as a backup not primary as tests, arm, disarm, etc. will otherwise disrupt normal use of the line, whereas the cellular does not.
 
So: Should POTS work as a backup to Cell?
 
Can you think of anything I may be doing wrong?   All I'm doing is swapping the two phone setups.  Each works independently.  But with Cell (uplink) first, POTS never fires, no matter what I do to make the cell fail.

 

[Del91574]

I have a site configured exactly as you with POTS/DSL as the secondary (they have ground faults on the Telco in that area).
 
Have you put a butt set on the line to see if it's actually going off hook?
 
Are there rules or other configurations that are in the background?
 
Did you assign an account number to the backup?

 

[Linwood]

My apologies for the lack of an answer.  I never received the email from the "follow".   
 

I have a site configured exactly as you with POTS/DSL as the secondary (they have ground faults on the Telco in that area).
 
Have you put a butt set on the line to see if it's actually going off hook?

 
Indirectly, the home phones are not going off line from it seizing the line.
 

Are there rules or other configurations that are in the background?

 
Yes, but nothing that I can see which affects the alarm state or dialing (in fact I can't find anything that affects dialing in rules, period, and almost nothing that affects alarms other than to arm, disarm and bypass.   So I'm fairly confident.  I really have very little in there, mostly emails for each trouble that can show up, a couple of light activations.
\

Did you assign an account number to the backup?

 
Yes, same number.   The actual communicator entry works both for uplink and for POTS when each is enabled separately (i.e. disable uplink, enable pots - works; disable pots, enable uplink - works;  enable uplink (1) and pots (2)  - works;  enable uplink (1) then pull its cable, enable pots (2) - fails;  enable pots as (1), unplug it, enable uplink as (2) - works.
 
I wrote to Elk, they said they would forward to an engineer, no response.
 
One thing that would make this difficult to notice is that (at least in my mind) the obvious way to test the setup is just to disable (in the M1G) the primary dialer and see if the secondary works.  And it does.  It's only when you force a physical failure on the Uplink that you notice this issue.  I'm a bit paranoid (if a bit late testing it), and wanted to test real failure scenarios, not just that the device worked.

 

[RAL]

 
The actual communicator entry works both for uplink and for POTS when each is enabled separately (i.e. disable uplink, enable pots - works; disable pots, enable uplink - works;  enable uplink (1) and pots (2)  - works;  enable uplink (1) then pull its cable, enable pots (2) - fails;  enable pots as (1), unplug it, enable uplink as (2) - works.

 
If I understand what you are doing, you are disconnecting the serial cable to the Uplink as a means of simulating a failure.  This makes me wonder whether the M1 is waiting for some sort of response from the serial port as to whether the cellular call was successful or unsuccessful.  And when it gets nothing at all because the cable is disconnected, it just waits and waits.   That would be a design bug in my book and something that Elk should fix.
 
It would be interesting to see if the failover to POTS worked if you did something else to cause a cellular failure, like removing the antenna from the Uplink.

 

[Linwood]

If I understand what you are doing, you are disconnecting the serial cable to the Uplink as a means of simulating a failure.  This makes me wonder whether the M1 is waiting for some sort of response from the serial port as to whether the cellular call was successful or unsuccessful.  And when it gets nothing at all because the cable is disconnected, it just waits and waits.   That would be a design bug in my book and something that Elk should fix.
 
It would be interesting to see if the failover to POTS worked if you did something else to cause a cellular failure, like removing the antenna from the Uplink.

 
I did that and didn't get the uplink lost message, and guessed that I have a strong enough signal it could communicate without the antenna.  I haven't actually tested a call without it, but I can do that.
 
However, I also simulated a failure by disconnecting the serial board (i.e. from the M1G).  The M1G noticed that as a module failure (whatever it called it, I don't remember right now, but it did so correctly), however it still did not call on the POTS line.  I was surprised by that, as I was guessing this was that the serial board was buffering the messages somehow.  But I still didn't get a POTS dial.
 
I do get a POTS dial every time if it's marked as the only one enabled, and I think I get one every time if it is marked as the second enabled for "dial every time" not as backup (I have done less experimenting there).

 

[Linwood]

Elk was kind enough to forward this to one of their engineers who responded that the uplink should not be used as a primary with the intent to fail over to a backup, it should be the only, or it should be a backup (or I guess an "also").  
 
Here is their response: 
 

Thank you for bringing this oversight to our attention. In most cases Cellular/GSM Radios would normally be used as a Backup to the Primary Plain Old Telephone (POTs) Land Line or would itself be the Primary means of communication. We never envisioned nor is it possible to have a Backup when the UpLink is configured as Primary. If the UpLink is installed into an area with sufficient signal strength it is assumed the signals will always be sent. The UpLink does not send an Acknowledgement back when the alarm condition is received. Because an Acknowledgement isn’t sent the M1 would never know there was a “Failed To Communicate” and switch to the Back Up means of communication.
 
You can use the UpLink as a Backup to your Land Line or setup Dual communication with both set to Always Report but you can’t have the UpLink as Primary and the Land Line as Backup.
 
Once again Thank you for bringing this to our attention and our Product Manager will make the necessary changes in the Installation Manuals to reference this fact.

 
Since I'm not an installer I thought it was very kind and professional that they took my original email and researched and reacted to it, kudos to them for keeping their DIY customer base engaged, and looking into an unusual situation.