News:

The OBiTALK service has reached it's End of Life period and will be decommissioned as of October 31st, 2024. More information can be found at this link https://support.hp.com/us-en/document/ish_10969583-11049883-16

Main Menu

Remotely Monitor Off-Hook Status?

Started by PhiDeck, January 16, 2015, 02:57:55 PM

Previous topic - Next topic

PhiDeck

Use Case: Early Alzheimer's live-alone patient forgetting to hang up the phone.

Can OBi1x0 and/or OBi20x be used to remotely monitor whether its connected phone is off-hook?
If so, by what push or pull mechanisms?:
- Browser
- IOS App
- E-mail
- SMS Text
- SSH
- Other?

zorlac

I know that you can check the "onhook" status through the obi web portal in expert mode but I doubt there's a way to have it assert that status automatically.

PhiDeck

Quote from: zorlac on January 16, 2015, 07:00:09 PM
I know that you can check the "onhook" status through the obi web portal in expert mode but I doubt there's a way to have it assert that status automatically.

Thanks, I will explore that avenue.  Using a scripted browser to obtain that datum is probably the least desirable means of doing so, compared to an API or a rule-based server initiated trigger, but one works with what one has.

Is there a way to explore the web portal prior to buying a unit?

infin8loop

If you are up to running a syslog, Off-Hook and On-Hook messages are written to the syslog.

I posted a perl syslog sample that could be modified to look for the Off-Hook and On-Hook message
here http://www.obitalk.com/forum/index.php?topic=185.msg9107#msg9107

The mechanics of what would be done with the messages makes my head hurt a bit. I'd probably take a low-tech approach and maintain a hook-status.txt file with a single line containing the last know status and date/time (updated from the syslog message).  Then I'd have another process running continuously that contained a timer loop that popped, say, every 10 minutes to track the status contained in the hook-status.txt file. If it was in Off-Hook too long, one might assume someone forgot to hang up the phone and send out an email to a caregiver. You could probably get fancy and monitor call termination messages in the syslog as well.

I run a free papertrailapp.com syslog on my one of my obi110's and it contains:

Jan 17 16:14:28 obi1 logger: [SLIC]:Slic#0 OFF HOOK   
Jan 17 16:14:53 obi1 logger: [SLIC]:Slic#0 ONHOOK

from a test call I made.

Best wishes as you help someone deal with the insidious disease of Alzheimer's.
 
"This has not only been fun, it's been a major expense." - Gallagher

infin8loop

Hook status of an Obi110 can be retrieved on the local page:

http://local-ip-address-of-obi/PI_FXS_1_Stats.xml

The above address could be posted by a script and the results retrieved and parsed by the script.

This might be a good use for a Raspberry Pi. 

"This has not only been fun, it's been a major expense." - Gallagher

Ostracus

Had something similar. That's why a 202 can come in handy in if one line's off-hook, the other will still ring.

PhiDeck

Quote from: infin8loop on January 17, 2015, 02:48:02 PM
If you are up to running a syslog, Off-Hook and On-Hook messages are written to the syslog.

I posted a perl syslog sample that could be modified to look for the Off-Hook and On-Hook message
here http://www.obitalk.com/forum/index.php?topic=185.msg9107#msg9107

The mechanics of what would be done with the messages makes my head hurt a bit. I'd probably take a low-tech approach and maintain a hook-status.txt file with a single line containing the last know status and date/time (updated from the syslog message).  Then I'd have another process running continuously that contained a timer loop that popped, say, every 10 minutes to track the status contained in the hook-status.txt file. If it was in Off-Hook too long, one might assume someone forgot to hang up the phone and send out an email to a caregiver. You could probably get fancy and monitor call termination messages in the syslog as well.

I run a free papertrailapp.com syslog on my one of my obi110's and it contains:

Jan 17 16:14:28 obi1 logger: [SLIC]:Slic#0 OFF HOOK   
Jan 17 16:14:53 obi1 logger: [SLIC]:Slic#0 ONHOOK

from a test call I made.

Best wishes as you help someone deal with the insidious disease of Alzheimer's.
Thank you.  I am leaning toward a syslog solution, pending determining the granularity of control of what gets logged.  I would host the syslog server on a Raspberry Pi, which would also process the log, sending appropriate emails to my cell phone provider's email-to-SMS gateway.

The RPi could also cycle power to the cordless phones' base-station, although more often the patient is using the corded phones (bigger and fewer buttons).

PhiDeck

Quote from: infin8loop on January 17, 2015, 03:15:15 PM
Hook status of an Obi110 can be retrieved on the local page:

http://local-ip-address-of-obi/PI_FXS_1_Stats.xml

The above address could be posted by a script and the results retrieved and parsed by the script.

This might be a good use for a Raspberry Pi. 

Agreed.  And I already have a RPi, so could test concept before buying another dedicated one.
Leaning toward the RPi hosting and processing the OBi syslog, though.

PhiDeck

Quote from: Ostracus on January 17, 2015, 06:35:36 PM
Had something similar. That's why a 202 can come in handy in if one line's off-hook, the other will still ring.
Seems like a good solution for the non-cognitively-impaired, particularly if they have 2-line phones.

Not clear on the applicability to an Alzheimer's patient, though.  Having to follow the ring to answer a separate dedicated phone on the second line may be asking too much.  As well as then having to identify the off-hook phone and hang it up.

I'll be happy if I can call the retired neighbor who is almost always home, who can cross the street and hang up the phone for the patient.  Have two back-up neighbors if primary is out.

PhiDeck

Thanks to all who replied.  On the basis of the info provided, and what I've discerned from on-line documentation, I ordered an OBi110, which'll arrive tomorrow.

Once I experiment, decide on a preferred approach, and implement and deploy the chosen solution, I'll report back here for closure.

PhiDeck

Unwelcome finding: it appears that the address of the syslog server must be hardcoded (numeric IP).
Was expecting the option of entering the server's name, and have the OBi110 use DNS to resolve it.

infin8loop

Quote from: PhiDeck on January 22, 2015, 06:17:40 AM
Unwelcome finding: it appears that the address of the syslog server must be hardcoded (numeric IP).
Was expecting the option of entering the server's name, and have the OBi110 use DNS to resolve it.

Sorry I didn't recall and/or mention the OBi syslog address must be an IP address.  I found out the hard way when I was setting up my papertrailapp.com account on the OBi110 and the URL did not work. I simply pinged the host address and used the IP address for the OBi syslog. I think papertrailapp syslogs probably use a load balancing system because I didn't always get the same IP address on pings. Luckily the one I chose seems to be working. I found the following official papertrailapp answer to the same question today: "Feel free to ping logs.papertrailapp.com and use whichever address is returned. It's quite common for embedded devices to only accept an IP, so a lot of Papertrail customers do exactly the same thing."  So I guess I did the correct thing back when I was shooting from the hip.

I was thinking your Raspberry Pi syslog would be at the patient's home alongside the OBi or tucked away somewhere safe (same network) and would be configured with a static IP address.

But if you want the Raspberry Pi in your home and want a Rube Goldberg solution (I can't stop my brain sometimes, forgive me) you could try this:

1. Run your syslog on a free papertrailapp.com account:
The syslog port number is not the default 514 but should be set to the port number assigned in the papertrailapp.com account and use a fixed IP for logs.papertrailapp.com (see above verbose background). The IP probably won't change (famous last words...)

2. You probably already have a dynamic dns service like www.noip.com to route a URL to your Raspberry Pi.  Use the URL in the next step.

3. Set an alert notification on the papertrailapp.com syslog to send the OFFHOOK and ONHOOK events to a "Webhook: POST matching events as JSON to an HTTP/HTTPS URL".  The URL would be the URL from #2 above pointing to your Raspberry Pi.

4. Write a JSON service to be run on the Raspberry Pi.  I have to bail on this one. I don't know JSON. I could probably learn it (wishful thinking) but my laziness knows no boundaries.

As a halfazzed proof of concept I setup an alert notification to my email address on my papertrailapp syslog that looks like this:

    SearchName: HOOKSTATUS
    Query:      "Slic#0 OFF HOOK" OR "Slic#0 ONHOOK"

One test, I received an email with:
Jan 23 22:18:03 obi1 logger: [SLIC]:Slic#0 OFF HOOK
Jan 23 22:18:14 obi1 logger: [SLIC]:Slic#0 ONHOOK

I used a one-minute time increment on the alert frequency. I had never tried the alert notifications. So I learned something today. I made the query an "OR" because two separate alert queries resulted in emails coming in with events out of order (sometimes). Trust me on this one.

I left out some detail in the flowchart. That would be where the "miracle occurs". 

This is where I pass the underinflated football and you catch it and run in for a touchdown.  ;D


"This has not only been fun, it's been a major expense." - Gallagher