AlexxIT/go2rtc · error

failed to subscribe to lowPower topic

Error message

failed to subscribe to lowPower topic: %w

What it means

WakeUp subscribes to the lowPower topic smart/decrypt/in/{deviceId} (QoS 1) so onLowPowerMessage can receive dps[149] status updates; a failure of that SUBSCRIBE token is wrapped in this error. The wake-up publish succeeded but the client cannot listen for the camera's response. Without the subscription, subsequent status updates are lost.

Solutions

  1. Verify broker ACL/permissions allow SUBSCRIBE on smart/decrypt/in/{deviceId}
  2. Check connection state before subscribing and reconnect if needed
  3. Retry the subscribe with backoff; a transient disconnect usually resolves on reconnect
  4. Confirm the deviceId is exact — a malformed topic can be rejected

Example fix

// before
err := client.WakeUp(deviceID)
// after
err := client.WakeUp(deviceID)
if err != nil && strings.Contains(err.Error(), "subscribe to lowPower") {
    time.Sleep(time.Second)
    err = client.WakeUp(deviceID)
}
Defensive patterns

Strategy: retry

Validate before calling

if deviceID == "" { return errors.New("empty deviceId prevents lowPower subscription") }

Try / catch

err := client.WakeUp(deviceID)
if err != nil && strings.Contains(err.Error(), "subscribe to lowPower") {
    time.Sleep(500 * time.Millisecond)
    err = client.WakeUp(deviceID)
}

Prevention

When it happens

Trigger: client.Subscribe(lowPowerTopic,...) returns a non-nil token error: broker rejected the subscription (ACL/auth), the connection dropped between publish and subscribe, or the topic filter is invalid.

Common situations: Broker ACLs that deny wildcards or the decrypt topic, credentials lacking subscribe rights on the shared topic, or flaky connections to low-power camera MQTT brokers.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors


AI-assisted analysis of AlexxIT/go2rtc@c245815e75 (2026-09-07). Data as JSON: /api/errors/2c8952602341761f. Report an issue: GitHub.

Appendix: source

Thrown at pkg/tuya/mqtt.go:199

		b, err := hex.DecodeString(hexStr[i : i+2])
		if err != nil {
			return fmt.Errorf("failed to decode hex: %w", err)
		}
		payload[i/2] = b[0]
	}

	// Publish to wake-up topic: m/w/{deviceId}
	wakeUpTopic := fmt.Sprintf("m/w/%s", c.deviceId)
	token := c.client.Publish(wakeUpTopic, 1, false, payload)
	if token.Wait() && token.Error() != nil {
		return fmt.Errorf("failed to publish wake-up message: %w", token.Error())
	}

	// Subscribe to lowPower topic to receive dps[149] status updates
	// (we don't wait for this signal - camera responds immediately)
	lowPowerTopic := fmt.Sprintf("smart/decrypt/in/%s", c.deviceId)
	if token := c.client.Subscribe(lowPowerTopic, 1, c.onLowPowerMessage); token.Wait() && token.Error() != nil {
		return fmt.Errorf("failed to subscribe to lowPower topic: %w", token.Error())
	}

	return nil
}

func (c *TuyaMqttClient) SendOffer(sdp string, streamResolution string, streamType int, isHEVC bool) error {
	// Map Skill StreamType to MQTT stream_type values
	// streamType comes from GetStreamType() and uses Skill StreamType values:
	// - mainStream = 2 (HD)
	// - substream = 4 (SD)
	//
	// But MQTT expects mapped stream_type values:
	// - mainStream (2) → stream_type: 0
	// - substream (4) → stream_type: 1

	mqttStreamType := streamType
	switch streamType {
	case 2:

View on GitHub (pinned to c245815e75)