Google Smart Home onExecute delay when turning on smart fan (Node.js + Firebase + MQTT)

Pallab_Mishra — Tue, 19 Aug 2025 05:02:15 GMT

I am integrating Google Smart Home with my IoT devices (Node.js + Firebase Functions + MQTT).
When the user says “Turn on fan”, the onExecute handler is triggered, but the fan operation happens with a noticeable delay (2–3 seconds).

Here’s the relevant flow in my code:

app.onExecute(async (body, headers) => { const { requestId } = body; const intent = body.inputs[0]; const commandResults = []; for (const command of intent.payload.commands) { for (const device of command.devices) { const deviceId = device.id; const parts = deviceId.split('_'); const boardSerial = parts[0]; const switchId = parts[1] || null; await withLock(boardSerial, async () => { await Promise.all(command.execution.map(async (execution) => { await updateDevice(execution, body, headers, boardSerial, switchId); // inside updateDevice -> publishes MQTT command (VG094:11) to topic })); }); commandResults.push({ ids: [deviceId], status: 'SUCCESS', states: { on: true, online: true } }); } } return { requestId, payload: { commands: commandResults }, }; });

The updateDevice function publishes MQTT commands (encrypted with key/iv) to the device’s topic.

After that, I also call reportState to update Google HomeGraph.
Devices eventually respond, but the Google Assistant action feels slow compared to Alexa integration with the same backend.

What I’ve tried / noticed:

If I publish directly to MQTT (bypassing Google onExecute), the fan reacts instantly.
Delay seems to come from my cloud function or how I handle subscriptions inside updateDevice.
I already added a withLock per device to avoid parallel execution clashes.
I suspect client.on('message') listeners or subscribe/unsubscribe inside updateDevice may be introducing delay.

Question:
How can I reduce the delay in the Google Smart Home onExecute → MQTT execution path?

Should I avoid dynamic subscribe/unsubscribe inside updateDevice and instead maintain a persistent subscription?
Is there a better pattern for publishing MQTT commands in response to Google Smart Home intents (so the device action is instant)?

Re: Google Smart Home onExecute delay when turning on smart fan (Node.js + Firebase + MQTT)

Suc_dpe — Thu, 21 Aug 2025 17:51:58 GMT

Hello,

The delay comes from creating subscriptions or cold starts inside onExecute. To fix this, maintain a persistent MQTT client (don’t dynamically subscribe/unsubscribe on every request), publish directly during execution, and call reportState after the action. If you’re on Firebase Functions, set minInstances to reduce cold-start lag.

To your specific questions:

Should I avoid dynamic subscribe/unsubscribe? → Yes, use a persistent connection instead.
Is there a better pattern for publishing MQTT commands? → Yes, keep the MQTT client alive, publish immediately on onExecute, and then update Home Graph with reportState. This ensures the device action feels instant.

topic Re: Google Smart Home onExecute delay when turning on smart fan (Node.js + Firebase + MQTT) in Smart Home Developer Forum

Google Smart Home onExecute delay when turning on smart fan (Node.js + Firebase + MQTT)

Re: Google Smart Home onExecute delay when turning on smart fan (Node.js + Firebase + MQTT)