ESP-AT New Features Collection

[ustccw]

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

[MaJerle]

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.

[como-221e]

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

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

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

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]

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

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

[JAndrassy]

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

[RomeliFeng]

About Wi-Fi roaming feature.

[ustccw]

About Wi-Fi roaming feature.

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

[MaJerle]

How to make UDP server to be discovered by Alexa?

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

[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

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

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

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

Thanks.
What is the AT command sequence to get UDP packets in local network on port (let's say) 1234?

[JAndrassy]

[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

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

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]

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

[lukegluke]

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.

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

[ustccw]

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

[foldl]

BLE 5.x features

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

[ustccw]

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]

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

[matt-wood-ct]

[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

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

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

I think for me this would be OK, is there a branch or bin I can try?

Many Thanks,
Matt

[xcguang]

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

[lippit]

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

[ustccw]

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

thanks for the feature request. will add this in one month.

[ustccw]

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

it's not a bad idea, we had considered it before. but file operation will cost massive flash space and ram space, so it is not that common for all esp chips. such as ESP8266 and ESP32-C2 has a relatively less flash and ram so that esp-at disabled the FS commands.

btw, esp-at has a light private key and certificate update steps here: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html

[MaJerle]

@ustccw - what if we use AT+SYSFLASH commands to hardcode load information there? Can we do it? I simply want to avoid modify official AT command firmware coming from Espressif. I want to load everything through AT commands.

[ustccw]

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

[MaJerle]

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

I don't think so, actually. In the AT+SYSFLASH command, I see:

Please make sure that you have downloaded at_customize.bin before using this command. For more details, please refer to How to Customize Partitions.

So it means I have to build on my own, no?

[ustccw]

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

I don't think so, actually. In the AT+SYSFLASH command, I see:

Please make sure that you have downloaded at_customize.bin before using this command. For more details, please refer to How to Customize Partitions.

So it means I have to build on my own, no?

in the released firmware: https://docs.espressif.com/projects/esp-at/en/latest/esp32/AT_Binary_Lists/ESP32_AT_binaries.html
there should already include the at_custommize.bin.

[ustccw]

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

this commit should include it: 5435e9a
could you please give it a try.

[Jacques-Zhao]

@matt-wood-ct When we tested USB AT, we found a serious problem, because WiFi and USB share the phy clock, the USB output could get stuck when WiFi and USB are used together, which caused the ESP32-C3 to not support the USB AT solution.

[Jacques-Zhao]

@matt-wood-ct I've uploaded the patch that implements USB AT, which can be used for testing. It should be noted that this patch cannot be used for production.
0001-feat-support-ESP32-C3-using-USB.patch

[DynamicLoader]

Hi,
I would like to suggest a new communication method.
Today's firmware transport events,network data,commands over a single path,UART/SPI. I wonder that if the data transfer from SPI, and command from UART;when there is an event, use a GPIO to inform the host instead of directly print on the UART. The host could query the events with a new command(let's say AT+CEVT and AT+SYSEVT).
It's a method for the improvement of stability and speed, which will also simplify the programing on the host side.
Best wishes!

[MaJerle]

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

[ustccw]

Hi, I would like to suggest a new communication method. Today's firmware transport events,network data,commands over a single path,UART/SPI. I wonder that if the data transfer from SPI, and command from UART;when there is an event, use a GPIO to inform the host instead of directly print on the UART. The host could query the events with a new command(let's say AT+CEVT and AT+SYSEVT). It's a method for the improvement of stability and speed, which will also simplify the programing on the host side. Best wishes!

@DynamicLoader May I ask why you didn't consider using SPI interface for both AT commands and data? Are there any specific limitations?

To be honest, ESP-AT did consider supporting multiple medium interfaces (including UART, SPI, SDIO, socket, etc., similar to netif on the PC side, managed through routing). However, this feature was later abandoned mainly due to the following reasons:

• From a product perspective, having multiple medium interfaces would increase hardware costs and require more PCB wiring.
• The existing design already fulfills the functionality of the majority of products.

Therefore, the general firmware does not support this feature.
If you indeed require commands to be sent/recv via UART and data to be sent/recv via SPI, you can modify the code (located in the https://github.com/espressif/esp-at/tree/master/main/interface directory) to redirect the SPI interface's command transmission and reception to UART.

[ustccw]

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

@MaJerle thanks for your proposal. will discuss it internally and feedback here within one week.

[ustccw]

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

sorry for late reply. We have had an in-depth internal discussion regarding this requirement, and we believe that AT+CIPSTARTEX is not very suitable for scenarios with multiple connections (AT+CIPMUX=1). Typically, AT+CIPSTARTEX is more suitable for single connections (AT+CIPMUX=0). If used in a multi-connection scenario, it only supports one connection with the link_id == 0.

[MaJerle]

Then we can remove cipstartex command, no?

[ustccw]

Then we can remove cipstartex command, no?

i'm afraid not. For compatibility reasons, we have to keep this command. However, we do not highly recommend using this command in multi-connection mode.

[mrx23dot]

Allow scanning in BLEINIT 2 (dual role) #743

[MaJerle]

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?

As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.

Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.

Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

[mrx23dot]

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?

As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.

Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.

Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

crc32, not SHA-256 on embedded

[MaJerle]

Add option to receive +CIPSNTPTIME: reply in yyyy-mm-dd hh:mm:ss, rather than in user friendly format.

ESP-AT is used by dedicated host, not for "user friendly" day in a week. Option can be done with SYSMSG if we need backward compatibility. It can reduce the processing on HOST and it is generally not needed in the format as we have today.

[MaJerle]

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?
As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.
Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.
Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

crc32, not SHA-256 on embedded

CRC32, with very defined CRC specifications, can indeed also work. I agree.

[salvathor79]

What about adding parameters to AT+WSCFG (or AT+WSOPEN) and AT+HTTPCLIENT to manage SSL certificate verification, i.e. like the parameters used in AT+MQTTUSERCFG?
Unfortunately AT+CIPSSLCCONF configure only the connection made with AT+CIPSTART.

[MaJerle]

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?
As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.
Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.
Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

crc32, not SHA-256 on embedded

@ustccw can we get a reply on this one please? Actually several options may be added (CRC32, SHA1, MD5, SHA-256).

[kaidegit]

[WebSocket][Server] 可以支持一下ws服务器吗，对于开不出ws服务器的小程序、uniapp等来说交互可能会更方便些

[ustccw]

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?

As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.

Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.

Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

Hello @MaJerle , thanks for your suggestion. esp-at uses manufacturing nvs stores all the data now, and nvs itself has the features you mentioned. NVS will reject writing data if the data to be written is the same as the data already written; NVS will write to different sectors to prevent excessive erasure of the same sector; NVS has its own CRC32 check.

[ustccw]

Add option to receive +CIPSNTPTIME: reply in yyyy-mm-dd hh:mm:ss, rather than in user friendly format.

ESP-AT is used by dedicated host, not for "user friendly" day in a week. Option can be done with SYSMSG if we need backward compatibility. It can reduce the processing on HOST and it is generally not needed in the format as we have today.

the time format comes from asctime() style, you can obtain each sub-item by the space delimiter.

[ustccw]

What about adding parameters to AT+WSCFG (or AT+WSOPEN) and AT+HTTPCLIENT to manage SSL certificate verification, i.e. like the parameters used in AT+MQTTUSERCFG? Unfortunately AT+CIPSSLCCONF configure only the connection made with AT+CIPSTART.

I would like to suggest customizing a your own AT command for configuring HTTP/WebSocket certificates and connecting to the server. Typically, HTTP/WebSocket servers do not require clients to provide certificates.

[ustccw]

[WebSocket][Server] 可以支持一下ws服务器吗，对于开不出ws服务器的小程序、uniapp等来说交互可能会更方便些

在 IoT 设备上运行 WebSocket 服务器，不是一个好的设计。因为 IoT 设备资源受限，导致无法满足多客户端的连接，也难以支持诸多服务器端丰富的特性；另外一点，服务器一般用于给其他客户端提供服务的，而 IoT 设备通常是没有广域网 IP 的，不太能直接给客户端提供服务。