Developing Asterisk voicemail interface

I am developing a new interface to allow interacting with Asterisk voicemail via home-assistant

Note that this is not meant to be an interface to configure Asterisk. Its only purpose is to provide a front-end to listen to voicemails.

There is a new Mailbox panel:

Each message contains:

  • Caller-ID
  • Date
  • Speech-to-Text conversion of audio
  • Playback (via wav->mp3 conversion)
  • Ability to delete messages

There is also a sensor to indicate the number of messages

The code is all functional, but there is some additional cleanup to be done

You can monitor the progress here:

3 Likes

I think this is a great idea- we have a voip phone that we basically just use for voicemail, and my family has had a lot of trouble with missing voicemails. Iā€™d love to get this into hass!

Can I get a little better understanding of the intended operation? Right now it only appears to be updating once upon hass startup in my environment- it is supposed to be polling the asterisk_mbox server? I see events flying around on the asterisk_mbox side, but nothing coming back into hass.

I also didnā€™t get the delete or the playback going either- one thing at a time! On the delete end of things- i know the request is making it to the asterisk_mbox side, but havenā€™t looked much further than that.

This has obviously seen limited testing, Iā€™m sure having others test it will help make it more robust.

It should work as followis:
The asterisk-mbox-serevr is started on the asterisk server. It will monitor the VM directory. and send all clients an update when there are changes.

The client connects to the server on HASS startup. It should receive changes in real time and display them as they come.
Playback is achieved by a requiest from the client to the server which does a real-time translation via LAME to mp3 and then streams the result back to the client.

Delete isnā€™t yet implemented on the server (though the client has all the necessary code already). The reason is because I implemented it at the same time as CDR monitoring, and the latter isnā€™t working, and then I got distracted with some other projects.

If you arenā€™t seeing updates, the most likely cause would be that the inotify code which monitors the VM directory isnā€™t working. That is something else Iā€™ve redone in my development branch, and should work on other platforms. What OS is your asterisk running on? If it is linux, than it should work as is. If not, Iā€™m not 100% sure.

Your HASS logs should indicate communication I think

okay thanks for the explanation there- just trying to get a general understanding before I dive deeper. Iā€™ll fork your asterisk-mbox repo so I can contribute to it. I think the inotify piece is OK because I do see messages flying around when I run the service at the command line, and I leave a voicemail. Iā€™m running it on archlinux.

The part I was missing was the part where HASS was to be notified. I think I missed the callback that is supposed to be sending something to connected clients. Iā€™m running asterisk+asterisk_mbox_server all on 1 machine, and hass is on a separate box.

Anyway- iā€™ll dig into it and let you know what I find.

Okay- havenā€™t had much time to work on this, but Iā€™m starting to get a little further into why this isnā€™t working for me.

Upon first startup, hass calls over to mbox server, and parses the resulting JSON just fine.

However, when mbox server alerts hass to an update (after i leave a message), hass throws this error:

File ā€œ/home/xxxx/home-assistant/homeassistant/components/asterisk_mbox.pyā€, line 73, in
key=lambda item: item[ā€˜infoā€™][ā€˜origtimeā€™],
TypeError: string indices must be integers

Temporarily commenting out those lines causes hass to work.
I put in some extra debugging on the mbox server side to dump out the json so I could look at it- it looks fine- meaning it should find an ā€œinfoā€ item and an ā€œorigtimeā€ item.
Any ideas on what might be different between when hass asks for a mailbox status vs. mbox server alerting hass?

Can you dump out the jcon to the log at line 72 and either file a ticket on gthub with it, or PM me the json (leave the error in place temporarily to make sure the error actually occurs)? Hopefully it will be clear up the issue. I was thinking it may be a race condition where the file is read before it has fully been written, but Iā€™ll need to see the JSON to see what is going on