1) I try dialing on house lines. There is dialtone, but dialing on Panasonic and simple DTMF phone leads to odd tones. Dialing home from cell goes to Ooma VM.
2) I unplug house line from Telo for 10 sec and reattach. No change in behavior. Still dialtone and odd tones when dialing out, and dialing in goes to Ooma VM. So, dialtone and odd tones apparently not coming from the Telo!
3) I bypass alarm, removing it from house line. Now no dial tone locally, no odd tones, no dialing out. Dialing in goes to Ooma VM.
4) I power cycle Telo, operations return to normal.
1) Odd tones are from from the alarm panel.
2) Dialtone to house line is being provided by alarm panel, not the Telo.
3) I suspect problem is between Telo and alarm panel. Now that alarm panel is disconnected, problem should not occur again if this is correct.
4) When problem occurs, it leaves Telo in a non-functioning analog state since removing alarm panel from loop doesn't restore Telo dialtone.
As problem has occurred roughly weekly, I'll give it a month with the alarm panel disconnected to not reoccur. If it doesn't, then I can start troubleshooting alarm panel handling of incoming line and how it might cause problem. Although the Telo analog line is disconnected from alarm, the alarm keypad doesn't show comm failure, and a dial test shows "phone ok". Must be it has failed over to cell communications and the loss of the analog line only generates the initial telco fault report in. I'll leave 92 alone for now and see what happens in the interim.
After googling around I found a document titled the "Digital Communication Standard -Ademco ® Contact ID Protocol for Alarm System Communications". It describes the protocol the panel uses to communicate. The communication consists of three components: a "Handshake Tone sequence", "MessageBlocks", and "Acknowledgements."
"5.1.1 Handshake Tones
The Handshake Tone sequence is produced by the RECEIVER. The purpose is to signal the TRANSMITTER that the communication channel is ready."
The Handshake Tone sequence is emitted by the receiver after going off-hook and delaying an interval of at least 0.5 seconds but typically no greater than 2.0 seconds.This time allows the phone network connection to settle before the communication process begins"
The handshake tone sequence shall consist of:
•A burst of 1400 Hz. ±3% tone with a duration of 100 msec. ±5%
•A pause of 100 msec. ±5%
•A burst of 2300 Hz. ±3% tone with a duration of 100 msec. ±5%"
Listening to those tones, and comparing to the handshake frequencies by ear (http://onlinetonegenerator.com/), makes me believe the short tone low-high, are these.
Then there is this:
"5.1.3 Kissoff (Acknowledgement) Tone
The Kissoff tone from the receiver is used to tell the transmitter that the message has been received successfully. The frequency of the tone shall be 1400 Hz. ±3% and shall be sent by the receiver for a minimum of 750 msec. and a maximum period of 1 second. The transmitter must detect a minimum of 400 msec. of tone before considering the kissoff to be valid"
"5.1.4Maximum Number of Attempts
The transmitter shall make up to 4 attempts to deliver a message before hanging up and redialing. The attempts counter is reset each time a valid kissoff signal is received."
The long tone sounds like it is this kissoff.
So, my panel is playing the part of the receiver, trying to tell a transmitter that it's ready to talk. What I managed to record were 3 of 4 intervals worth of attempts to communicate composed of a handshake, kissoff pair. Figuring this out gave me a happy moment
So now there are two questions.
1) What is sending the panel into this communications state, seemingly after an incoming call (with answering machine defeat on the panel disabled)? Related: why does the panel remain in this state until the Telo is rebooted?
2) Why, when the panel is bypassed when the fault occurs, does the Telo remain "hung" with a blue "normal operations" flower but no dial tone?
I've also discovered the magic of the RJ31X jack which seemed to be a redundantly useless connection by the panel until I came across its secret. When the panel is not plugged in, the jack shunts the phone line to the rest of the house. When the panel is plugged into the RJ31X, the jack shunts the phone line to the panel which permits the panel to either return it to the rest of the house via the RJ31X for normal operation, or seize the line.
I'd bypassed the panel entirely, including the RJ31X, when I pulled it out of the loop for this most recent test. I'm going to put that back in, leaving the panel unpluged while waiting to see if the problem happens again as I look into what conditions might send the panel into this reception mode.
Set *95 to 0 This disables station initiated downloading.
These changes should make the panel ignore all incoming phone calls.
There is no reason for your panel to ever answer a phone call unless a central office technician is standing in front of the panel. He would know how to reinstate those fields if he needed them.
Telo with 2 Handsets, a Linx, and a Safety Phone
Telo2 with 2 Handsets and a Linx
Reading the protocol a bit more, it turns out message block data is sent during download via regular DTMF tones, which may explain why my attempt to tone dial during a failure was perceived as an attempt to send data to the panel and greeted with handshake/kissoff tones.
Question still remains though, what is sending the panel into the 'ready to download' state? When on my old regular POTS line, the answering machine defeat was enabled and would occasionally pick up on an immediately following second call with an annoying fax-like sound, but hanging up on that call left the panel in a normal state of operation.
There was an incoming call which Ooma website call logs show got through (green arrow) at 9:48am. There was a corresponding answering machine message timestamped 9:47am that was one minute of silence. The blank answering machine message is a new behavior that didn't occur when alarm panel was in the loop. Two later calls that day show a red X in the Ooma website call logs, showing those calls didn't get through, but they didn't leave a message so I wasn't alerted to the issue via that route.
When I got home I tried calling out. No dialtone, and of course call didn't complete. That's when I discovered the problem. Incoming call from cell did not ring house phone and went to Ooma VM where I left a message. That call also showed up with a red X in the call logs. Checking the Telo at this point, the "flower" was in normal blue state. The VM light on the Telo was flashing and when I pressed it, I heard the VM I'd just left, so the Internet side of the Telo is working fine. Just the analog side is dying.
I plugged the alarm panel back into the loop, rebooted the telo, and got dialtone, but dialing led to alarm panel beeps. I unplugged alarm panel again and there was no dialtone. I rebooted telo again, did successful dial-in test from alarm panel when flower was blue, and then things were operating correctly.
Next steps will be to remove things one at a time from the line, starting next with FAX, and wait to see what happens. If this were a test-bed I'd start with a single phone and add things in one at a time after a month of no problems, but this is a working home and I want to minimize functionality loss as I run this to ground. I just have to rule out all the devices before the 1 yr. warranty on the Telo is up when only a faulty Telo or problematic firmware would remain as possible cause.
No Fax or Alarm connected on the line.
Incoming calls went directly to VM, Ooma showed as online on the web, no dial tone, and the Telo showed the blue flower, normal status. I had to power reset the unit to restore normal operation.
I have been using this replacement Telo for about 6 months or so, after the original one, that was several years old, had a different intermittent problem. This was the first serious outage with the new Telo, especially concerning since we were unaware. I will be monitoring carefully for any repeats of the problem, and I'm considering putting the unit on a remote switch, as you did, but that obviously will just be a workaround, not satisfactory for permanent use.
I just confirmed that Voicemail is generating emails with messaging, at least when Ooma is operating properly, and I did receive a Voicemail with the first missed call during the failure. FWIW, the last successful connection prior to the failure was an inbound international call for about 15 minutes.