Share your ideas, use cases & feedback!

[n-IA-hane]

Hey everyone! 👋

We'd love to hear from you. Whether you're already using the intercom components or just exploring what's possible, this is the place to share:

• Ideas: features you'd like to see, integrations that would be useful, UI improvements
• Use cases: how are you using (or planning to use) the intercom system? Apartment intercom, baby monitor, whole-house audio, office paging, accessibility...
• Hardware setups: which ESP32 boards, codecs, displays are you running? What works well?
• Questions & discussions: anything related to the project

Feel free to discuss anything that interests you. There are no bad ideas, your feedback helps shape the direction of the project.

Looking forward to hearing from you! 🎙️

[apaneiro]

Integrate existing doorbell as additional contact. Display video both in esphome and in the Lovelace card with Open Door button. Doorbell config in the Intercom integration - Name, Camera entity, Audio requirements, Open door entity. HA as bridge. Send camera and open door details to Esphome A quinta, 12/03/2026, 18:49, n-IA-hane ***@***.***> escreveu:

…

Hey everyone! 👋 We'd love to hear from you. Whether you're already using the intercom components or just exploring what's possible, this is the place to share: - *Ideas* — features you'd like to see, integrations that would be useful, UI improvements - *Use cases* — how are you using (or planning to use) the intercom system? Apartment intercom, baby monitor, whole-house audio, office paging, accessibility... - *Hardware setups* — which ESP32 boards, codecs, displays are you running? What works well? - *Questions & discussions* — anything related to the project Feel free to discuss anything that interests you. There are no bad ideas — your feedback helps shape the direction of the project. Looking forward to hearing from you! 🎙️ — Reply to this email directly, view it on GitHub <#17>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARBOACGJY4WCJTEO7WAPP2L4QMBEBAVCNFSM6AAAAACWQB4CZOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGYZTENJRGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[n-IA-hane]

Hi. I reply you about PR. Yes, I wasted the whole weekend, but now every component is well-balanced in terms of load. JTAG was very useful for understanding how the processes run under the hood. Everything that could be moved in PSRAM to free up the ESP's main RAM has been moved. The ESP can now breathe better. I also made some improvements to the i2s audio duplex. By combining all these things, the overall quality of operation has significantly improved. Buffers, samples, and tasks are now all resized, optimized, and aligned with attention to resource conservation. Have you tried the Micro wake word on the AEC mic output? It's working perfectly for me. About the PR Thanks for the help. I'll wait until I have some time to test your improvements. The touch screen is a great idea, and yes, I also think it could be applied to the intercom only option. As for the auto-answer feature, it's not difficult to implement in the code. I was already researching this, but from what I've read, browsers, including those running in web apps like Companion, don't seem to be able to trigger audio, video, or input capture without the user pressing a key for security reasons. Perhaps these measures are designed to prevent data exfiltration by some Trojan. So, it's likely you could answer via an automation, but I'm worried the call might remain silent because no key was pressed to confirm the user's conscious choice. I'm not 100% sure about this yet. In any case, I was thinking about expanding the audio bridge's functionality. Add a call rejection service with reason. So, for example, you could reject a call from an automation and print the reason on the ESP display, such as "Hangup. User is away from home," or start implementing call diversion just like real phones do. You could use them in advanced automations such as if the ESP calls HA (guest at the door) and the user is at home then it diverts the call to the ESP at the entrance (where by pressing a binary sensor you can answer) , otherwise it sends a notification in the app, and the user answers from the app. What do you think?

[apaneiro]

MWW is also much effective now, great work. I left my automation as an additional comment on #19 If you find that my PR is useful, tomorrow I'll try to update the intercom.yaml to also support the touchscreen. A quarta, 18/03/2026, 19:46, n-IA-hane ***@***.***> escreveu:

…

Hi. I reply you about PR. Yes, I wasted the whole weekend, but now every component is well-balanced in terms of load. JTAG was very useful for understanding how the processes run under the hood. Everything that could be moved in PSRAM to free up the ESP's main RAM has been moved. The ESP can now breathe better. I also made some improvements to the i2s audio duplex. By combining all these things, the overall quality of operation has significantly improved. Buffers, samples, and tasks are now all resized, optimized, and aligned with attention to resource conservation. Have you tried the Micro wake word on the AEC mic output? It's working perfectly for me. Thanks for the help. I'll wait until I have some time to test your improvements. The touch screen is a great idea, and yes, I also think it could be applied to the intercom only option. As for the auto-answer feature, it's not difficult to implement in the code. I was already researching this, but from what I've read, browsers, including those running in web apps like Companion, don't seem to be able to trigger audio, video, or input capture without the user pressing a key for security reasons. Perhaps these measures are designed to prevent data exfiltration by some Trojan. So, it's likely you could answer via an automation, but I'm worried the call might remain silent because no key was pressed to confirm the user's conscious choice. I'm not 100% sure about this yet. In any case, I was thinking about expanding the audio bridge's functionality. Add a call rejection service with reason. So, for example, you could reject a call from an automation and print the reason on the ESP display, such as "Hangup. User is away from home," or start implementing call diversion just like real phones do. You could use them in advanced automations such as if the ESP calls HA (guest at the door) and the user is at home then it diverts the call to the ESP at the entrance (where by pressing a binary sensor you can answer) , otherwise it sends a notification in the app, and the user answers from the app. What do you think? — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARBOACEUW3FTP6SM7PVCLIT4RL4LDAVCNFSM6AAAAACWQB4CZOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJZG43TSNY> . You are receiving this because you commented.Message ID: ***@***.*** com>