Device / version
- Model: Shelly Wall Display XL (BLAKE, SAWD-3A1XE10EU2), app 3.26157.2133
Issue 1 — silent failure on schemeless broker URI
If mqttBroker is set without a URI scheme (e.g. 10.0.2.13 instead of tcp://10.0.2.13), the client never connects. Logcat shows only:
MQTT: Connecting...
MQTTServer: publishInternal skipped, client not connected: .../bri (repeating)
No error, no timeout, no log line indicating the cause. The broker (Mosquitto) shows no connection attempt at all. Setting mqttBroker to tcp://10.0.2.13 fixes it immediately:
MQTTServer: Connected to tcp://10.0.2.13:1883
MQTTServer: publishConfig: topic=homeassistant/device/.../config ... components=25
Suggestion: either default/normalize a missing scheme to tcp://, or surface a clear error/log when the URI can't be parsed, instead of hanging silently.
Issue 2 — reconnect after settings change doesn't take effect
After changing MQTT settings at runtime, the app logs:
MQTTServer: Settings changed - reconnecting with new config
HttpServer: Failed to start http server: java.net.BindException: EADDRINUSE (Address already in use)
…but the MQTT client does not actually reconnect — it keeps logging publishInternal skipped, client not connected. Only a full reboot applies the corrected settings. The EADDRINUSE suggests the previous socket/server isn't being torn down before the reconnect.
Expected: changing MQTT settings should cleanly tear down and re-establish the connection without a reboot (the docs state "Running components react immediately, you don't need to reboot").
Device / version
Issue 1 — silent failure on schemeless broker URI
If mqttBroker is set without a URI scheme (e.g. 10.0.2.13 instead of tcp://10.0.2.13), the client never connects. Logcat shows only:
No error, no timeout, no log line indicating the cause. The broker (Mosquitto) shows no connection attempt at all. Setting mqttBroker to tcp://10.0.2.13 fixes it immediately:
Suggestion: either default/normalize a missing scheme to tcp://, or surface a clear error/log when the URI can't be parsed, instead of hanging silently.
Issue 2 — reconnect after settings change doesn't take effect
After changing MQTT settings at runtime, the app logs:
…but the MQTT client does not actually reconnect — it keeps logging publishInternal skipped, client not connected. Only a full reboot applies the corrected settings. The EADDRINUSE suggests the previous socket/server isn't being torn down before the reconnect.
Expected: changing MQTT settings should cleanly tear down and re-establish the connection without a reboot (the docs state "Running components react immediately, you don't need to reboot").