cancel
Showing results for 
Search instead for 
Did you mean: 

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

Pallab_Mishra
Community Member

 

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)?

1 Recommended Answer

Suc_dpe
Solutions Expert
Solutions Expert

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.

View Recommended Answer in original post

1 REPLY 1

Suc_dpe
Solutions Expert
Solutions Expert

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.