esp-at icon indicating copy to clipboard operation
esp-at copied to clipboard

ESP-AT New Features Collection

Open ustccw opened this issue 4 years ago • 58 comments
trafficstars

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

  1. Please navigate to ESP-AT User Guide and search features to avoid creating duplicates before you comment on the feature request.
  2. Please describe the feature you'd like, as clear and understandable as possible.

C. Sample of New Feature Request

  1. [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

ustccw avatar Feb 26 '21 12:02 ustccw

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.

MaJerle avatar Feb 26 '21 12:02 MaJerle

[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 avatar Mar 01 '21 10:03 como-221e

[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 avatar Mar 01 '21 11:03 como-221e

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.

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.

ustccw avatar Mar 01 '21 11:03 ustccw

[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.

ustccw avatar Mar 01 '21 11:03 ustccw

[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.

ustccw avatar Mar 08 '21 03:03 ustccw

[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.

JAndrassy avatar Apr 03 '21 18:04 JAndrassy

About Wi-Fi roaming feature.

RomeliFeng avatar May 23 '21 12:05 RomeliFeng

About Wi-Fi roaming feature.

Thank you. We have this plan in v2.3.0.0.

ustccw avatar May 24 '21 04:05 ustccw

How to make UDP server to be discovered by Alexa?

MaJerle avatar May 24 '21 04:05 MaJerle

[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.

ustccw avatar May 24 '21 07:05 ustccw

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

ustccw avatar May 24 '21 07:05 ustccw

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?

MaJerle avatar May 24 '21 08:05 MaJerle

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.

ustccw avatar May 24 '21 08:05 ustccw

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?

MaJerle avatar May 24 '21 08:05 MaJerle

[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

JAndrassy avatar May 24 '21 08:05 JAndrassy

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.

ustccw avatar May 24 '21 08:05 ustccw

[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.

ustccw avatar May 24 '21 09:05 ustccw

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.

lukegluke avatar Jul 01 '21 13:07 lukegluke

[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 avatar Oct 22 '21 17:10 TakashiKusachi

[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.

ustccw avatar Oct 29 '21 03:10 ustccw

BLE 5.x features

AT commands for BLE 5.x features, such as extended advertising, PHY management, etc.

foldl avatar Dec 16 '21 09:12 foldl

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.

ustccw avatar Dec 27 '21 03:12 ustccw

@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.

ustccw avatar Mar 31 '22 11:03 ustccw

[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 avatar May 10 '22 10:05 matt-wood-ct

@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.

xcguang avatar May 10 '22 10:05 xcguang

@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 avatar May 10 '22 10:05 matt-wood-ct

@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.

xcguang avatar May 12 '22 09:05 xcguang

[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.

lippit avatar Jul 15 '22 17:07 lippit

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

MaJerle avatar Sep 04 '22 08:09 MaJerle