# \[Feature Request\] Microphone support in Dashboards **URL:** \ **Category:** Ideas & Suggestions\ **Tags:** featurerequest\ **Created:** [April 29, 2026, 8:19pm UTC](https://community.homey.app/t/feature-request-microphone-support-in-dashboards/154361 "2026-04-29T20:19:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jan\_Tendahl](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jan_tendahl/32/121229_2.png) [@Jan\_Tendahl](https://community.homey.app/u/Jan_Tendahl)\ **Post date:** [April 29, 2026, 8:19pm UTC](https://community.homey.app/t/feature-request-microphone-support-in-dashboards/154361/1 "2026-04-29T20:19:22Z")
**Feature Request: Microphone Access in Dashboard Widgets (getUserMedia / Web Speech API)** **Summary** Please enable microphone access (`getUserMedia` / Web Speech API) in the Homey Dashboard widget WebView on iOS, Android, and macOS. * * * **Current Behavior** Dashboard widgets run inside a WebView. The APIs are technically present on mobile, but microphone access is blocked at the permission level on all platforms. This has been verified through a dedicated test widget that logs the full WebView environment on button press: | Platform | SpeechRecognition | getUserMedia | Result | | --- | --- | --- | --- | | **iOS 26.5** (iPhone) | ✅ present | ✅ present | ❌ `not-allowed` | | **Android 16** (Samsung Galaxy Tab, WebView `wv`) | ✅ present | ✅ present | ❌ `NotAllowedError: Permission denied` | | **macOS** (Homey desktop) | ❌ undefined | ❌ undefined | ❌ completely unavailable | All platforms report `isSecureContext: true`, so the context itself is not the problem — the Homey app simply does not forward microphone permissions to the WebView. * * * **What We’re Asking For** Expose microphone access to widget WebViews by making the following changes in the Homey native app: **iOS / macOS:** 1. Add `NSMicrophoneUsageDescription` to `Info.plist` 2. Implement `WKUIDelegate.webView(_:requestMediaCapturePermissionFor:initiatedByFrame:type:decisionHandler:)` to grant microphone requests from widget WebViews **Android:** 1. Add `RECORD_AUDIO` permission to `AndroidManifest.xml` 2. Implement `WebChromeClient.onPermissionRequest()` to grant `PermissionRequest.RESOURCE_AUDIO_CAPTURE` for widget WebViews * * * **Use Case** A voice-controlled smart home dashboard widget. The user presses a microphone button on their dashboard tablet, speaks a natural language command (e.g. _“turn on the hallway light”_ or _“water the lawn for 10 minutes”_), and the widget sends the recognized text to a local Homey app API. The app then uses AI to semantically match the command to the correct Homey flow or device and executes it — including setting multiple capability values in the right order (e.g. `watering_duration=10` then `onoff=true`). The speech recognition itself uses the **browser’s built-in Web Speech API** — entirely on-device, no external STT service, no data leaves the local network for the speech step. This would unlock a completely new category of Homey widgets: **hands-free, voice-controlled dashboards** without requiring any external hardware (no Echo, no Google Home, no dedicated voice hardware). * * * **Why This Matters** - 🎤 No third-party speech-to-text service required — Web Speech API is built into every modern mobile browser - 🔒 Privacy-friendly — speech recognition runs on-device and only if a button in the dashboard is pushed. - 📱 Natural fit for tablet-based always-on dashboards - 🏠 Other smart home platforms (e.g. Home Assistant via its companion app) already support this - ⚡ The fix is a small native code change on each platform — the WebView side is already ready and working * * * **Current Workaround** None within the Homey app. Users must rely on Siri Shortcuts, Google Assistant, or the dictation function in third-party apps (e.g. Teams) to get voice input into Homey flows. * * * Thank you for considering this — it would be a significant upgrade for anyone running a dashboard-first smart home setup. ---
**Author:** ![Clem](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/clem/32/173237_2.png) [@Clem](https://community.homey.app/u/Clem)\ **Post date:** [September 27, 2026, 10:59am UTC](https://community.homey.app/t/feature-request-microphone-support-in-dashboards/154361/2 "2026-09-27T10:59:06Z")
👋 +1 for this request, with a second use case: a video doorbell / intercom widget. Everything else already works inside a widget: ring event from a Flow, live WebRTC video, doorbell audio (AAC transcoded to Opus through go2rtc) and a door-open action. Only talking back is missing. Two findings from my tests (Homey app on iOS, Homey Self-Hosted Server 13.5.0): - Calling navigator.mediaDevices.getUserMedia({ audio: true }) in a widget does not return NotAllowedError: it crashes the Homey app. This looks like the typical iOS behavior when an app accesses the microphone without an NSMicrophoneUsageDescription entry in its Info.plist. - Homey.popup(url) opens an in-app browser where the microphone is granted, even on a page served by Homey ([homeylocal.com](http://homeylocal.com)). But it asks for permission on every call and cannot be closed from script, so it isn’t usable for an intercom. Adding NSMicrophoneUsageDescription and a WebKit media capture permission handler on iOS (and RECORD\_AUDIO + onPermissionRequest in the Android WebView) would unlock both voice commands and intercom widgets. Thanks a lot for considering it, and thanks @Jan_Tendahl for the detailed write-up! ---
**Author:** ![Goossens](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/goossens/32/172342_2.png) [@Goossens](https://community.homey.app/u/Goossens)\ **Post date:** [October 28, 2026, 9:07pm UTC](https://community.homey.app/t/feature-request-microphone-support-in-dashboards/154361/3 "2026-10-28T21:07:13Z")
Until this is supported: the keyboard’s microphone does work in a dashboard widget’s text box (dictation by the phone keyboard, not by the widget), so a widget can still take spoken input that way. That’s how my own chat widget handles it (Cortex AI, I made it): tap the box, use the keyboard mic, and it sends when you stop talking. Not a replacement for real microphone access, but usable today.