Bug: server auto-sleeps ~5s after post-wake greeting, before user can respond

[realdecimalist]

Summary

After the user triggers the Wake system capability and the platform plays its greeting TTS, the server sends devkit-action: {"action":"sleep"} + sleep-mode: {"enabled": true} ~4-5 seconds after the dashboard reports bot-speak-end for that greeting. The user has almost no window to actually speak before being kicked back to sleep mode.

Observed timeline (CDP tap on DevKit Chromium, 2026-04-24 12:47 UTC)

```
12:47:37.000 ← user said "hi penny wake up" (STT)
← wake capability fires, sleep-mode disabled
12:47:38.000 Penny: "👋 Hello there! What do you need help with today?"
12:47:38.??? → bot-speak-end (client → server, TTS done)
← devkit-action: {"action":"sleep"} ← server-initiated
← sleep-mode: {"enabled": true} ← fired twice
← sleep-mode: {"enabled": true}
12:47:42.000 Penny: "Going into sleep mode call my name to wake up"
```

Total active window: ~4 seconds from wake → re-sleep. The normal idle timeout after any other turn is ~60s. Something in the post-wake code path has a much shorter window.

Why it's a platform bug, not a client one

Inspected the Pi dashboard source (openhome_devkit/openhome-dashboard-pi/src/App.tsx):

• handleDevkitAction receives action: "sleep" and hits the default: console.warn("Unknown devkit action: sleep"); return; branch — no local action taken.
• handleSleepMode just sets sleepModeRef.current = true — passive.
• "bot-speak-end" is only sent from the browser on normal TTS completion or user-initiated interrupt. Not tied to sleep.

So the client is passively obeying a server decision. The devkit-action: sleep originates from the server immediately upon receiving bot-speak-end for the wake greeting.

Reproduction

1. Put Penny in sleep mode ("Penny, sleep" or idle-wait to timeout)
2. Wait until sleep-mode: {"enabled": true} observed
3. Wake her with a wake trigger ("hey Penny" / "wake up")
4. Let her greeting TTS play to completion, without speaking
5. Within ~4-5 seconds of bot-speak-end, the server sends another devkit-action: sleep + sleep-mode: true, re-sleeping the session

100% reproducible across multiple sessions. Reproduced on personality_id: 578906 with a DevKit Pi, Chromium 137 dashboard build as of 2026-04-24.

Comparison with working case

In sessions where the user speaks DURING or IMMEDIATELY AFTER the greeting TTS, the re-sleep does NOT fire. The idle timer only trips when there's no user speech in the post-greeting window. So the short window is specifically post-wake.

Request

1. Lengthen the post-wake idle window from ~4-5s to match the normal idle timeout (~60s). This is a one-config fix if the window is a named constant.
2. Alternatively: cancel the post-wake idle timer when the user speaks or when any subsequent capability-fire event happens.

Workaround we shipped on our end

Patched the Pi dashboard (openhome-dashboard-pi/src/App.tsx) to:

• Detect final assistant messages with chat_details.name === "wake"
• Defer sending bot-speak-end for that message by up to 30 seconds
• Flush the deferred send immediately when user STT reports live/final speech

This prevents the server from starting its short idle timer until the user actually responds (or 30s elapses). Not a platform fix — just a workaround to keep us productive while this is open.

Environment

• OpenHome personality 578906, DevKit Pi at 192.168.0.175
• Chromium 137.0.7151.119
• No custom dashboard mods beyond mic sensitivity + echo cancellation flags (both documented separately)
• System abilities installed: Wake, Sleep, Persistent Memory, Change Personality, Date & Time, Live Web Search, Listen to Sound
• No Brain Skill system capability modifications

Happy to share the full CDP tap output if useful.

[uzair401]

Hello @realdecimalist, could you please share which firmware version you were using with the DevKit?

[uzair401]

Thanks @realdecimalist for raising this — we’re looking into it and will fix it soon.