esp-at
esp-at copied to clipboard
ESP-AT New Features Collection
ESP-AT New Features Collection
A. Brief Introduction
Currently, many AT commands have been added to the esp-at project, but esp-at still does not meet the requirements of all products.
Here, we are committed to extracting some common features and adding them to the general esp-at firmware to reduce the cost of customer development, accelerate the landing of customer products and inject fresh blood into the esp-at project at the same time.
So...o, suggest any feature request for this project would be welcomed!
B. Code of Conduct
- Please navigate to ESP-AT User Guide and search features to avoid creating duplicates before you comment on the feature request.
- Please describe the feature you'd like, as clear and understandable as possible.
C. Sample of New Feature Request
- [MQTT][ALPN] Hope AT+MQTT command support ALPN Short Description: As the AWS Device communication protocols designed, clients that connect on port 443 with X.509 client certificate authentication must implement the Application Layer Protocol Negotiation (ALPN) TLS extension and use the ALPN protocol name listed in the ALPN ProtocolNameList sent by the client as part of the ClientHello message.
D. Feature Statistics
| Status | Feature Description | Plan | Note |
|---|---|---|---|
| Done | [MQTT][ALPN] MQTT supports ALPN configuration | / | supported after d16e75f |
| Done | [SNTP] support the synchronization interval setting | / | supported after e8d4c34 |
| Done | [BLE] support BLE 5.0 | v2.4.0.0 | supported after 19b48fe |
| Won't Do | [USB] ESP32-C3 supports USB interface | / | it's unstable if Wi-Fi and USB are used together |
| TODO | [BT] support passive read for bluetooth data | v2.4.0.0+ | / |
| Won't Do | [Wi-Fi] support Wi-Fi roaming | / | 1. Roaming has to be initiated by AP; 2. 802.11r only make sure that we will skip 4 way handshake during roam; 3. Device may get disconnected for various reasons, right now we don't initiate roaming automatically based on disconnection; 4.It was more a request from customer in mesh solutions in which they expect devices to move automatically between the APs as APs wants and timing should be pretty low. |
| TODO | [TCP/IP] AT+CIPSERVER supports more servers | v2.4.0.0+ | / |
| Won't Do | [MQTT over WS] Customize HTTP header | / | not common |
I've been asking for better AT+CIPSTART implementation with AT+CIPSTARTEX, where application doesn't set connection number by itself. Instead, we should do it like that:
-> AT+CIPSTARTEX="TCP",and_other_thingsCRLF
<- +CIPSTARTEX:0,conn_num_assigned_by_ESP
<- +CIPSTARTEX:1,1 (if connect OK)
<- +CIPSTARTEX:1,0 (in case of failure)
<- OK
In this case we have well defined strategy when we use client and server at the same time. Otherwise we may have race conditions.
However all pushes have been well defined w/o proper argument.
[MQTT][ALPN] ALPN support within the MQTT client. Short description: It would be useful to have ALPN enabled within the SSL layer of the MQTT client in such a way that MQTT connections can be established with ports typically used for other protocols (e.g. port 443). This may come handy with AWS (see here).
[MQTT over WS][HTTP header] Customized HTTP header with MQTT over web socket client. Short description: It would be useful to customize the header of the HTTP request related to the opening of a web-socket based MQTT client, in order to pass over to the server additional info, like token authentication parameters. Currently this can be done by adding the parameters to the "path" field of the AT+MQTTUSERCFG but this is limited to the 32 bytes max length of such field and therefore not much useful.
I've been asking for better AT+CIPSTART implementation with AT+CIPSTARTEX, where application doesn't set connection number by itself. Instead, we should do it like that:
-> AT+CIPSTARTEX="TCP",and_other_thingsCRLF <- +CIPSTARTEX:0,conn_num_assigned_by_ESP <- +CIPSTARTEX:1,1 (if connect OK) <- +CIPSTARTEX:1,0 (in case of failure) <- OKIn this case we have well defined strategy when we use client and server at the same time. Otherwise we may have race conditions.
However all pushes have been well defined w/o proper argument.
Hi @MaJerle, esp-at has the command AT+SYSMSG, enable BIT1 of the command could get detailed connection prompt information. I am not sure if this meets your requirements.
[MQTT][ALPN] ALPN support within the MQTT client. Short description: It would be useful to have ALPN enabled within the SSL layer of the MQTT client in such a way that MQTT connections can be established with ports typically used for other protocols (e.g. port 443). This may come handy with AWS (see here).
@como-221e Thanks for the feedback, had added to the esp-at TODO list.
[MQTT over WS][HTTP header] Customized HTTP header with MQTT over web socket client. Short description: It would be useful to customize the header of the HTTP request related to the opening of a web-socket based MQTT client, in order to pass over to the server additional info, like token authentication parameters. Currently this can be done by adding the parameters to the "path" field of the AT+MQTTUSERCFG but this is limited to the 32 bytes max length of such field and therefore not much useful.
@como-221e In fact, the path parameter configured by the AT+MQTTUSERCFG command will be passed to the "GET %s HTTP/1.1" of the websocket connection establishment request, which indicates the resource path, other than authentication item.
Generally speaking, authorization is implemented through wss certificate or subprotocol of websocket. It is recommended that use username and password parameter of MQTT to authorize.
If authorization is mandatory in websocket request, user can modify the implement of websocket here. https://github.com/espressif/esp-idf/blob/master/components/tcp_transport/transport_ws.c#L147 Furthermore, could you please submit an issue in esp-idf to request the authorization function of webwocket.
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with port. what is the reason for the one server limit? a TCP server has no overhead.
About Wi-Fi roaming feature.
About Wi-Fi roaming feature.
Thank you. We have this plan in v2.3.0.0.
How to make UDP server to be discovered by Alexa?
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.
This is not easy to add this feature to ESP-AT common firmware. Because:
- Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance.
- The work may not be easy, it may involve almost all the TCP/IP AT commands.
Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
How to make UDP server to be discovered by Alexa?
AFAIK, udp may not have the concept of server. udp can receive the data from the port which it listens, or send the data to the port. Maybe you can take a look:
- https://docs.espressif.com/projects/esp-at/en/latest/AT_Command_Set/TCP-IP_AT_Commands.html#establish-udp-transmission
- https://docs.espressif.com/projects/esp-at/en/latest/AT_Command_Examples/TCP-IP_AT_Examples.html#exam-UDPTrans
Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port?
Is there a way for "any" IP?
Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port?
Is there a way for "any" IP?
emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.
Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port? Is there a way for "any" IP?
emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.
Thanks.
What is the AT command sequence to get UDP packets in local network on port (let's say) 1234?
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.
This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance. 2. The work may not be easy, it may involve almost all the TCP/IP AT commands.Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed.
as bonus AT+CIPDINFO could configure local port info into +IPD EDIT: CONNECT announces a new connection, not +IPD
Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port? Is there a way for "any" IP?
emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.
Thanks. What is the AT command sequence to get UDP packets in local network on port (let's say)
1234?
I am not sure what kind of udp packet type Alexa sends out. let's say it is the udp broadcast. so the AT commands like the following:
AT+RESTORE
AT+CWMODE=1
AT+CWJAP="ssid","password"
AT+CIPSTART="UDP","255.255.255.255",1234
more see as: https://docs.espressif.com/projects/esp-at/en/latest/AT_Command_Set/TCP-IP_AT_Commands.html#establish-udp-transmission.
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.
This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance. 2. The work may not be easy, it may involve almost all the TCP/IP AT commands.Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed. as bonus AT+CIPDINFO could configure local port info into +IPD
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.
This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance. 2. The work may not be easy, it may involve almost all the TCP/IP AT commands.Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed. as bonus AT+CIPDINFO could configure local port info into +IPD
i can understand what you expected, there is always a way to be as compatible as possible with previous AT commands. esp-at will consider this feature when esp-at updates to an incompatible large version in the future.
Classic Bluetooth SPP - improve receiving.
Currently on data receiving there is URC filled with data: +BTDATA:4,test Length of data is not limited by anything and could exceed limited resources of external MCU and/or can be reported in not appropriate times. It is quite bad strategy to demand external MCU to receive all data immediately once ESP is received it wirelesslly. Also bluetooth data in general and useful cases is binary and parsing raw binary data that can be received at any times inconvenient and demands modification of common AT line parsers.
It would be more convenient to have only a notification (indicator) about new data receiving in URC (+BTSPPRCV:<conn_index>). And then user can use additional command something like AT+BTSPPREAD=0,255 (read data from SPP id 0, max length is 255 bytes).
AT+BTSPPREAD response:
+BTSPPREAD:<data_len>
<data>
OK
This way it would be much easier to parse raw binary data that can includes <0>, <CR>, <LF>.
Also it would be convenient to support request about length of data available in buffer: AT+BTSPPREAD=0,0
+BTSPPREAD:<totalreceivelength>,<havereadlength>,<unreadlength>
OK
This way is similar to Quectel M66 GSM module with Bluetooth, I like how they implemented it. And as I see ESP32 TCP-IP commands already use this approach with notification +IPD, so it is doubly sad that bluetooth receiving doesn't follows common practice.
Please pay attention that other URCs must not interpose between +BTSPPREAD and OK.
[SNTP] Setting the synchronization interval https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/system_time.html?highlight=sntp#sntp-time- synchronization The URL above shows that you can add the ability to set the update interval. I would like to have this feature.
Another possible feature would be to force the time to synchronize.
As an additional question, in the current version (2.2.0), this synchronization interval is (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html# config-lwip-sntp-update-delay) of 3600000?
Translated with www.DeepL.com/Translator (free version)
[SNTP] Setting the synchronization interval https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/system_time.html?highlight=sntp#sntp-time- synchronization The URL above shows that you can add the ability to set the update interval. I would like to have this feature.
Another possible feature would be to force the time to synchronize.
As an additional question, in the current version (2.2.0), this synchronization interval is (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html# config-lwip-sntp-update-delay) of 3600000?
Translated with www.DeepL.com/Translator (free version)
@TakashiKusachi Thanks for your suggestion. we will add the feature to the next version.
BLE 5.x features
AT commands for BLE 5.x features, such as extended advertising, PHY management, etc.
BLE 5.x features
AT commands for BLE 5.x features, such as extended advertising, PHY management, etc.
@foldl ESP32-C3 supports BLE 4.2 now, and will supports BLE 5.0 in the next few months. we planed to release v2.4.0.0 for ESP32-C3 in March 2022, which includes BLE 5.0.
@foldl ESP32-C3 supports BLE 5.0 now, please get the latest code. esp-at plans to release v2.4.0.0 for ESP32-C3 in April 2022.
[INTERFACE][USB] Support for USB VCP as an at command interface
Short description:
Many hosts which use at command radios communicate using USB VCP rather then uart directly, it would be useful to either support USB VCP in parallel with the UART/SDIO or as a configuration option. Specifically on the ESP32-C3 Series where the VCP is a core feature of the IC/Module
@matt-wood-ct We has finished it, but it will output some logs to USB from ROM API, unfortunately, these logs cannot be masked. We can evaluate it again.
@matt-wood-ct We has finished it, but it will output some logs to USB from ROM API, unfortunately, these logs cannot be masked. We can evaluate it again.
I think for me this would be OK, is there a branch or bin I can try?
Many Thanks, Matt
@matt-wood-ct C3 USB need IDF v4.4 or later, we have not ported AT to this IDF. After release v2.4.0.0, we will do this. Pray to be released in two weeks.
[CWSTAPROTO][WIFI_PROTOCOL_LR] Support for long range protocol
Short description:
ESP IDF supports the proprietary Espressif WiFi long range protocol, defined in esp_wifi_types.h:
#define WIFI_PROTOCOL_LR 8
Unfortunately, setting this value with AT+CWSTAPROTO results in an error. Please add support for this protocol in AT firmware.
What about ability to set private key and public certificate for SSL connection via file operation commands like Quectel LTE modems? https://www.quectel.com/wp-content/uploads/2021/03/Quectel_BG96_SSL_Application_Note_V1.1.pdf