[Feature Request] Microphone support in Dashboards

[Jan_Tendahl]

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.

[Clem]

+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). 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!

[Goossens]

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.