Align docs with ESP32-S3 dashboard architecture

docs/UART_PROTOCOL.md

@@ -1,8 +1,10 @@
 # UART Protocol
 
-The Pico dashboard communicates with the ESP32 controller over UART.
+This document describes the optional UART JSON protocol supported by the ESP32 controller.
 
-UART is the primary dashboard/control link. HTTP should mirror the same concepts, but the Pico should be able to operate the controller without WiFi.
+UART is not the primary dashboard/control link. The current dashboard target is the Waveshare ESP32-S3 display over WiFi/HTTP.
+
+Keep this protocol for diagnostics, simulator work, service tools, or alternate clients. Do not treat it as evidence that a Pico dashboard is planned.
 
 ## Serial Settings
 
@@ -41,7 +43,7 @@ Temperature sensors:
 
 ## Status Request
 
-Pico sends:
+Client sends:
 
     {"type":"status_request"}
 
@@ -49,7 +51,7 @@ ESP32 responds with the same shape as HTTP /status.
 
 ## Relay Control
 
-Pico sends:
+Client sends:
 
     {"type":"set_relay","relay":"relay_1","enabled":true}
 
@@ -59,7 +61,7 @@ ESP32 responds:
 
 ## Config Request
 
-Pico sends:
+Client sends:
 
     {"type":"config_request"}
 
@@ -69,37 +71,37 @@ ESP32 responds:
 
 ## Device Name Update
 
-Pico sends:
+Client sends:
 
     {"type":"config_device","device_name":"Overland Controller"}
 
 ## Relay Config Update
 
-Pico sends:
+Client sends:
 
     {"type":"config_relay","id":"relay_1","name":"Aux Power","enabled":true}
 
 ## Temperature Sensor Config Update
 
-Pico sends:
+Client sends:
 
     {"type":"config_temp","id":"temp_1","name":"Cabin","address":"","enabled":true}
 
 ## BMS Config Update
 
-Pico sends:
+Client sends:
 
     {"type":"config_bms","enabled":true,"name":"House Battery","address":"aa:bb:cc:dd:ee:ff","address_type":"public"}
 
 ## Save Config
 
-Pico sends:
+Client sends:
 
     {"type":"save_config"}
 
 ## Factory Reset
 
-Pico sends:
+Client sends:
 
     {"type":"factory_reset"}
 
@@ -156,14 +158,14 @@ The UART protocol should eventually support the same management capabilities as
 
 ## Notes
 
-- UART is the preferred dashboard/control path.
-- HTTP is useful for setup, debugging, and future web UI.
+- HTTP is the preferred dashboard/control path.
+- UART is useful for diagnostics and alternate clients.
 - USB serial remains the emergency service/debug interface.
-- The Pico should not depend on WiFi for normal control.
+- No Pico dashboard is currently planned.
 
 ## WiFi Config Request
 
-Pico sends:
+Client sends:
 
     {"type":"wifi_request"}
 
@@ -173,19 +175,19 @@ ESP32 responds:
 
 ## WiFi Config Update
 
-Pico sends:
+Client sends:
 
     {"type":"config_wifi","ssid":"Starlink","password":"password_here"}
 
 ## WiFi Connect
 
-Pico sends:
+Client sends:
 
     {"type":"wifi_connect"}
 
 ## WiFi Clear
 
-Pico sends:
+Client sends:
 
     {"type":"wifi_clear"}
 
@@ -239,7 +241,7 @@ Lower priority numbers are tried first.
 
 ## Scan Temperature Sensors
 
-Pico sends:
+Client sends:
 
     {"type":"scan_temps"}
 
@@ -249,7 +251,7 @@ ESP32 responds:
 
 ## Assign Temperature Sensor
 
-Pico sends:
+Client sends:
 
     {"type":"assign_temp","id":"temp_1","index":1}
 
@@ -259,14 +261,16 @@ Alternative:
 
 ## Clear Temperature Sensor
 
-Pico sends:
+Client sends:
 
     {"type":"clear_temp","id":"temp_1"}
 
 Alternative:
 
-    {"type":"clear_temp","slot":1}\n\n### Temperature weather flag
+    {"type":"clear_temp","slot":1}
+
+### Temperature weather flag
 
 `status_response.config.temperature_sensors[]` and `status_response.temps[]` include `weather: false`.
 
-`config_temp` may include `weather: true` to mark one configured sensor as the outside/weather sensor. Pico clients should treat this as optional and default missing values to `false`.\n
+`config_temp` may include `weather: true` to mark one configured sensor as the outside/weather sensor. Clients should treat this as optional and default missing values to `false`.