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
- Verify broker ACL/permissions allow SUBSCRIBE on smart/decrypt/in/{deviceId}
- Check connection state before subscribing and reconnect if needed
- Retry the subscribe with backoff; a transient disconnect usually resolves on reconnect
- 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
- Grant subscribe ACLs for smart/decrypt/in topics on the broker
- Subscribe-then-publish ordering where your broker requires it
- Monitor Subscribe token errors in logs to detect ACL changes
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
- failed to publish wake-up message
- openIoTHubConfigResponse.Msg
- mqtt client is closed, send mqtt message fail
- failed to start MQTT
- loginResp.ErrorMsg
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)