blog: Move the blog to September

Author: david-cermak

content/blog/2025/08/esp-wifi-remote/at.drawio renamed to content/blog/2025/09/esp-wifi-remote/at.drawio

@@ -1,6 +1,6 @@
 ---
 title: "*esp-wifi-remote*: The remote control to your Wi-Fi"
-date: 2025-08-28
+date: 2025-09-05
 showAuthor: false
 summary: "**esp-wifi-remote** provides traditional `esp_wifi` functionality on non-WiFi targets, allowing them to act as a `host` that communicates with a WiFi-capable `slave` device through a transport layer."
 authors:
@@ -86,7 +86,7 @@ CONFIG_ESP_WIFI_AMPDU_RX_ENABLED -> CONFIG_WIFI_RMT_AMPDU_RX_ENABLED
 
 The backend solutions could perform a consistency check but cannot reconfigure the slave project.
 
-### Choice the backend solution
+### Choosing the backend solution
 
 The default and recommended option is `esp_hosted` as your backend solution for most use-cases, providing the best performance, integration, maturity and support.
 
@@ -97,13 +97,6 @@ Here are the reasons you might prefer some other implementation than `esp_hosted
 * You prefer encrypted communication between host and slave device, especially when passing WiFi credentials.
 * You might need some customization on the slave side
 
-### Internal implementation
-
-The `esp-wifi` component interface depends on WiFi hardware capabilities. `esp-wifi-remote` follows these dependencies based on the slave WiFi hardware. Some wireless and system capability flags are replaced internally with `SOC_SLAVE` prefix. Host-side config options are prefixed with `WIFI_RMT` for use in `esp-wifi-remote` headers. See [WiFi remote](https://github.com/espressif/esp-wifi-remote/blob/main/components/esp_wifi_remote/README.md#dependencies-on-esp_wifi) documentation for details.
-
-> 📝
-> These options and flags are only related to the host side, as `esp-wifi-remote` is a host side layer. For slave side options, please refer to the actual backend solution implementation.
-
 #### Comparison of backend solution components
 
 This section compares backend solutions, focusing on how different methods marshall WiFi commands, events and data to the slave device.
@@ -144,6 +137,13 @@ The best throughput is achieved with `esp_hosted` implementation.
 | wifi_remote_over_eppp | up to 20Mbps      | [eppp-link](https://github.com/espressif/esp-protocols/blob/master/components/eppp_link/README.md#throughput) |
 | wifi_remote_over_at | up to 2Mbps     | [esp-at](https://github.com/espressif/esp-at) |
 
+### WiFi Remote internals
+
+The `esp-wifi` component interface depends on WiFi hardware capabilities. `esp-wifi-remote` follows these dependencies based on the slave WiFi hardware. Some wireless and system capability flags are replaced internally with `SOC_SLAVE` prefix. Host-side config options are prefixed with `WIFI_RMT` for use in `esp-wifi-remote` headers. See [WiFi remote](https://github.com/espressif/esp-wifi-remote/blob/main/components/esp_wifi_remote/README.md#dependencies-on-esp_wifi) documentation for details.
+
+> 📝
+> These options and flags are only related to the host side, as `esp-wifi-remote` is a host side layer. For slave side options, please refer to the actual backend solution implementation.
+
 ## Other connectivity options
 
 This blog post focuses on *esp-wifi-remote* solutions only. It doesn't discuss Bluetooth, BLE connectivity, `esp-extconn` component or other means of using Wi-Fi library on remote targets.