Caller ID to Sonos

I have Sonos working. I want Sonos to announce the Caller ID when the phone rings.

Does anyone know of an inexpensive device that will get the CID into my Windows computer, or directly into Hubitat?

Landline, iOS, or Android? I think this is possible using Tasker on Android.

I have Vonage, which is a simulated (IP) landline. I woulld need something that would plug into a landline phone line.

For a landline, this should work:

  1. Get a Raspberry Pi
  2. Get a USB fax/modem and connect it to the Pi
  3. Get a phone line splitter so your vonage line is connected both to your phone and you RPi.
  4. Install NCID on the RPi

Finally create a text hub variable on your Hubitat and expose it via MakerAPI to the RPi. You can write a little script on the RPi to update the variable with the content of the decoded caller ID. Then create a Hubitat automation that reads out the contents of the variable anytime the variable changes.

Disclaimer:

I don't have this kind of setup, but I remember hearing about similar setups about 10-15 years ago.

Thanks for your input. I didn't think it would be this complex. I think this is more work than this project is worth.

You might want to check if Vonage has an API that lets you export this information.

There is an older YAC program that runs on Windows, versus using a RPI. But you still need a modem and splitter, per the above. And YAC can broadcast the alerts to the network which you could write an App on the HE to pickup that broadcast. (That's fairly easy, given it's output format is just a string)

But bottom line, you need a modem with CallerID as a service/daemon on SOME device (background 24x7 host) in your network, to pick up this info from you POTS line, and then there are various ways to get that into HE. You could also do the "annouce" directly to Sonos on the Windows box, just using the appropiate curl command and AWS Polly (to TTS), if you want to skip all the HE interface work. There are already numerous visual YAC clients for MediaPortal, Plex, etc.

See:

https://www.voip-info.org/forum/threads/yac-yet-another-callerid.4403/

I agree it's unlikely there's anything that could meet this need without a DIY/belt-and-suspenders approach. Although some solutions could be somewhat more or less convoluted than others.

The reason being that in the context of a phone call between two parties, caller ID information--whether you still use a POTS phone or VOIP--isn't really intended to be sent anywhere else.

Is it possible to use a linux or Windows PC to work around that? Sure, as mentioned above. But probably not in a quick and easy way.

Google says that Vonage has an API that exposes CID information. But I didn’t delve any deeper into it.

Right, I'm sure the devil is in the details (what kind of vonage device/plan, what exactly can that API do with that info, etc.).

I have a modem with CID. I have a splitter. I have a 24/7 Windows machine.

The USB modem is rather old and there are no model specific drivers to be found anywhere. It is a v.92 modem, but the Windows 11 Device Manager sees it as a v.90.

I'm not sure how to communicate with it.

I also have a USB Way2Call TAPI device, but also have no idea on how to communicate with it either.

Any ideas would be appreciated.

I tried the YAC program. It did not find my modem or my Way2Call TAPI device.

I will look for other programs that might see the Way2Call device.

I got a new modem and YAC is working and logging the CID to a file. YAC can broadcast the information to a specified IP and port.

It looks like I could Read the text file (log) from within a rule, but unless I'm running the rule every 2 seconds, I would need some way to trigger the rule when the phone rings.

Any help would be appreciated.

Glad to hear that you got the modem working with YAC, that's definitely the 1st step of the process. Given YAC's network abilities, I wouldn't mess with a file/log polling approach to try an pickup the data. Since you need an "active listener" on the HE side to pickup the unsolicited CID event, I would use the 39501 port on HE as the input mechanism, and it's fairly easy via a registry setting to change the output port of the YAC server from it's default 10629 to the HE port of 39501.

The remaining problem is two-fold:

  1. You need a HE driver to parse the YAC server alert, and I'm assuming you want 3 attributes: CallerID name, CallerID Number, Call DateTime - Where either the name/number could be NULL. I'm actually working on building such a user driver just to help with this, but it's not really all that complicated besides the parsing of the YAC output

  2. The 39501 port of HE, expects an HTTP packet, and YAC by default, is just sending a raw/simple TCP packet, with very little formatting. I have the source for YAC, and assuming I get #1 above complete, I believe I can preface the YAC output with an HTTP header, to make the HE parser happy, but that's going to require a tweak on the YAC sender side. Unfortunately, I don't know of any other easy way to get unsolicited strings data into HE. (perhaps MQTT if you know that technology? - But that still would require YAC changes).

The complete other choice, would be to do all this on the windows side, and just use sonos-http-api and have it directly do TTS to the Sonos speakers - You would need to install NodeJS on your windows server, and a short script to take the YAC network output, and send it to the proper Sonos HTTP output (which talks directly to the speakers), not sure if that would be easier, but it would not involve the HE hub and be overall simpler (less moving parts). But that depends if you need the CID info in HE for other RM or automation devices.

I'll work on getting a simple driver working, with a HTTP header "bolted" on a YAC output packet, and let me know if you want me to look at modifying the YAC sender code (Broadcast.c) to enable it to be processed via the 39501 port on the HE or if you think the Windows only/sonos-http-api approach is preferrable to you.

I think it would be much better for me if I could keep everything covered by Hubitat using the 39501 port. It would be super great if you could do this.