* fix: MQTT settings silently fail to persist when broker is unreachable
isValidConfig() was testing broker connectivity via connectPubSub() as
part of config validation. When the broker was unreachable (network not
ready, DNS failure, server down), the function returned false, causing
AdminModule to skip saving settings entirely — silently.
This removes the connectivity test from isValidConfig(), which now only
validates configuration correctness (TLS support, default server port).
Connectivity is handled by the MQTT module's existing reconnect loop.
Fixes#9107
* Add client warning notification when MQTT broker is unreachable
Per maintainer feedback: instead of silently saving when the broker
can't be reached, send a WARNING notification to the client saying
"MQTT settings saved, but could not reach the MQTT server."
Settings still always persist regardless of connectivity — the core
fix from the previous commit is preserved. The notification is purely
advisory so users know to double-check their server address and
credentials if the connection test fails.
When the network is not available at all, the connectivity check is
skipped entirely with a log message.
* Address Copilot review feedback
- Fix warning message wording: "Settings will be saved" instead of
"Settings saved" (notification fires before AdminModule persists)
- Add null check on clientNotificationPool.allocZeroed() to prevent
crash if pool is exhausted (matches AdminModule::sendWarning pattern)
- Fix test comments to accurately describe conditional connectivity
check behavior and IS_RUNNING_TESTS compile-out
* Remove connectivity check from isValidConfig entirely
Reverts the advisory connectivity check added in the previous commit.
While the intent was to warn users about unreachable brokers,
connectPubSub() mutates the isConnected state of the running MQTT
module and performs synchronous network operations that can block
the config-save path.
The cleanest approach: isValidConfig() validates config correctness
only (TLS support, default server port). The MQTT reconnect loop
handles connectivity after settings are persisted and the device
reboots. If the broker is unreachable, the user will see it in the
MQTT connection status — no special notification needed.
This returns to the simpler design from the first commit, which was
tested on hardware and confirmed working.
* Use lightweight TCP check instead of connectPubSub for validation
Per maintainer feedback: users need connectivity feedback, but
connectPubSub() mutates the module's isConnected state.
This uses a standalone MQTTClient TCP connection test that:
- Checks if the server IP/port is reachable
- Sends a WARNING notification if unreachable
- Does NOT establish an MQTT session or mutate any module state
- Does NOT block saving — isValidConfig always returns true
The TCP test client is created locally, used, and destroyed within
the function scope. No side effects on the running MQTT module.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Add ESP32 Power Management lessons learned document
Documents our experimentation with ESP-IDF DFS and why it doesn't
work well for Meshtastic (RTOS locks, BLE locks, USB issues).
Proposes simpler alternative: manual setCpuFrequencyMhz() control
with explicit triggers for when to go fast vs slow.
* Added a lambda function to clear startup output in the MQTT unit test to ensure a clean state before and after the MQTT subscription process.
* Add transmit history for throttling that persists between reboots
* Fix RAK long press detection to prevent phantom shutdowns from floating pins
* Update test/test_transmit_history/test_main.cpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Test fixes and placeholder for content handler tests
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
I thought git would be smart enough to understand all the whitespace changes but even with all the flags I know to make it ignore theses it still blows up if there are identical changes on both sides.
I have a solution but it require creating a new commit at the merge base for each conflicting PR and merging it into develop.
I don't think blowing up all PRs is worth for now, maybe if we can coordinate this for V3 let's say.
This reverts commit 0d11331d18.
* RoutingModule::sendAckNak takes ackWantsAck arg to set want_ack on the ACK itself
* Use reliable delivery for traceroute requests (which will be copied to traceroute responses by setReplyTo)
* Update ReliableRouter::sniffReceived to use ReliableRouter::shouldSuccessAckWithWantAck
* Use isFromUs
* Update MockRoutingModule::sendAckNak to include ackWantsAck argument (currently ignored)
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Added map report precision bounds
* Log warning
* Precision range should be 12-15
* Missed commit
* Update tests
* That method was renamed
* Removed now-defunct test call
* Remove defunct test
* Sanity check configuration for the default MQTT server
* Skip for MESHTASTIC_EXCLUDE_MQTT
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
