[Feature]: Talkback/Two-way audio implementation

Describe the solution you’d like

Hi!

I’ve implemented a proof-of-concept talkback or two-way audio feature for this repository and would love to hear your input/recommendations.

But first let me thank you for the amount of work you have put in this project, so that we can make so much more out of our eufy devices. While I was working on this I did some network and software analysis on the native eufy app. It seems to me that this repository completely relies on the 1.0 api version of the eufylive network.

1. do you have plans to move to the latest api version?
2. do you believe that eufy will eventually let the old api version die, so that this project will no longer work? (since the old eufy apps already show a big warning message that an upgrade is required to use eufy).

But now to the talkback feature:

You can find it in my fork under the feature-talkback branch: https://github.com/thieren/eufy-security-client/tree/feature-talkback

I have a battery doorbell from eufy.

• T8210 (firmware:2.2.3.3)
• Homebase T8010 (firmware 3.1.7.2h)

With this setup and a modified homebrigde-eufy-plugin (you can find it here: https://github.com/thieren/Homebridge-eufy-plugin/tree/feature-talkback) I am able to use the speech feature inside of HomeKit.

If you want I can open a draft pull request. But I don’t think that it is quite ready to merge it into this project yet, since some things are just missing.

What it does is quite simple. You can start and stop a talkback session while a p2p-stream is running. When the talkback session is confirmed from the station side a writeable stream is returned via EventEmitter. At last you can check whether talkback is supported for the device.

Since I own only a battery doorbell (T8210) this is the only tested and therefore supported device at the moment. But I suppose this approach should work for other devices too.

The input stream has to be of a specific format:

• AAC_LC (format: adts)
• 1 channel (mono)
• 16000 kHz
• ~16kbps/s (other bitrates might work, but I had best results with this)

An example ffmpeg command would be:

ffmpeg -i input.mp3 -acodec aac -ac 1 -ar 16k -b:a 16k -f adts pipe:1 The stdout of this process can directly be fed into the talkback stream.

Still ToDo:

• Test other devices
• Test other codec formats
• implement for more than one device per station (for now all is running for channel 0 -> first device)
• sanity checks for incoming audio data (is it the right codec/format, …)
• …

Open questions on my side:

• I found that you use another packet sequencing for energy saving devices. I didn’t dig really deep into this, since I don’t use that feature for myself. Is there a quick explanation, so that I can check whether this has to be accounted for here?

For me this works for now. If there is a demand I can try and improve this up to the point where it could be merged.

[bropat]

@thieren released 😉

[bropat]

Hi @thieren, thank you for testing and contributing. I think this weekend should be doable.