deploy: 9e73e9aaa0

cli_commands/index.html

@@ -2082,6 +2082,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#select-rak-oled-controller" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Select RAK OLED controller
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -5085,6 +5096,17 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#select-rak-oled-controller" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Select RAK OLED controller
+      
+    </span>
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -8047,14 +8069,30 @@ set display.rotation 270
 </code></pre>
 <p>The values are clockwise degrees. <code>0</code> clears the override and restores the
 board's compiled default. Unsupported display drivers return an error.</p>
-<p>RAK4631 and RAK3401 images detect SSD1306 or SH1106 OLED controllers when
-initializing the screen. This lets the same RAK4631 image serve WisMesh Pocket
-v2 and v3. Both retain rotation support and use one 1 KiB framebuffer.</p>
+<h2 id="select-rak-oled-controller">Select RAK OLED controller</h2>
+<p>Display-capable RAK4631 and RAK3401 images with OLED controller detection
+support a saved selection in Companion, Repeater, Room Server and Sensor roles:</p>
+<pre><code class="language-text">get display.controller
+set display.controller auto
+set display.controller ssd1306
+set display.controller sh1106
+</code></pre>
+<p>Choose <code>auto</code> for normal use. If a panel is shifted, wraps at its edge or is
+otherwise incorrectly detected, select its controller explicitly and restart
+the node. Changes are saved immediately and apply after restart; the current
+screen keeps its active controller until then. <code>get display.controller</code>
+reports the configured choice, active choice and whether a restart is
+needed. A custom firmware build is not needed to change this choice.</p>
+<p>Automatic detection lets the same RAK4631 image serve WisMesh Pocket v2 and
+v3. Both controllers retain rotation support and use one 1 KiB framebuffer.</p>
 <p>Detection checks the configured <code>DISPLAY_ADDRESS</code> (default <code>0x3C</code>). Only
 repeated SH1106 status readings select that controller; ambiguous responses
-keep SSD1306, preserving compatibility with older RAK1921 panels. For panels
-that cannot identify themselves, build with <code>OLED_CONTROLLER_OVERRIDE=1</code>
-(SSD1306) or <code>=2</code> (SH1106); <code>=0</code> restores automatic detection.</p>
+keep SSD1306, preserving compatibility with older RAK1921 panels. With no
+saved choice, the default is automatic detection unless the build sets
+<code>OLED_CONTROLLER_OVERRIDE=1</code> (SSD1306) or <code>=2</code> (SH1106). This build-time
+override remains a fallback for existing custom builds. Any saved selection
+takes precedence, including <code>auto</code>, which restores detection even when that
+fallback forces a controller.</p>
 <p>See <a href="https://github.com/meshcore-dev/MeshCore/issues/3296">the Pocket v3 issue</a>
 and <a href="https://github.com/meshtastic/firmware/pull/11265">the RAK1921 detection caveat</a>.</p>
 <hr />

firmware_picker/index.html

@@ -2921,6 +2921,10 @@ combined and single-transport names are explicit-build compatibility aliases.
 SSD1306 Full Companion builds use <code>set display.rotation 90|180|270</code>; <code>0</code>
 restores the board default, so a separate rotated release image is not
 recommended.</p>
+<p>New display-capable RAK4631 and RAK3401 images with OLED controller detection
+also offer saved <code>display.controller</code> choices: <code>auto</code>, <code>ssd1306</code> or <code>sh1106</code>.
+This applies after restart and avoids a custom image when a panel needs an
+explicit controller. See <a href="../cli_commands/#select-rak-oled-controller">controller selection</a>.</p>
 <p>New Heltec V4 R8 TFT images also support saved rotation in Companion,
 Repeater, Room Server and Sensor roles. The observer dashboard follows the
 selected portrait or landscape orientation. Once the canonical image proves

optional_screens/index.html

@@ -2370,7 +2370,7 @@ add detection to an older download.</p>
 <tr>
 <td>RAK WisBlock</td>
 <td>The <a href="https://downloads.rakwireless.com/Meshtastic/Quick%20Start%20Guide_WisMesh%20RAK4631%20Starter%20Kit.pdf">RAK4631 kit guide</a> labels the RAK1921 OLED optional.</td>
-<td>Existing display-capable SSD1306 images already check presence.</td>
+<td>Display-capable RAK4631 and RAK3401 images check presence and detect SSD1306 or SH1106 controllers. New images also provide a saved controller choice; see below.</td>
 </tr>
 <tr>
 <td>iKoka Stick and Handheld</td>
@@ -2403,6 +2403,15 @@ add detection to an older download.</p>
 recipe has no verified panel readback connection. Detection is not enabled for
 that wiring. A touchscreen acknowledgement alone does not establish that the
 LCD responds. The V4 R8 TFT and older V4 TFT pin mappings are distinct.</p>
+<p>RAK4631 and RAK3401 images with OLED controller detection support
+<code>set display.controller auto</code>, <code>ssd1306</code> or <code>sh1106</code> in all display-enabled
+roles. Keep <code>auto</code> for normal use; choose the panel's controller explicitly if
+detection gives shifted or wrapped pixels. The choice is saved and applies
+after restarting the node. <code>get display.controller</code> shows the configured and
+active choices and any pending restart. With no saved choice, automatic
+detection or an existing build-time override supplies the default; saved
+<code>auto</code> takes precedence over that override. Normal controller selection does
+not require custom firmware. See the <a href="../cli_commands/#select-rak-oled-controller">controller commands</a>.</p>
 <p>New R8 TFT images support saved <code>display.rotation</code> values of <code>0</code>, <code>90</code>, <code>180</code>
 and <code>270</code>, including portrait/landscape dashboard changes without reflashing.
 The stock R8 expansion board has no accelerometer for automatic orientation.

search/search_index.json

@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection   to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated