Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AT+SYSMSG=0 does not disable WiFi connection related messages #844

Open
3 tasks done
BornaBiro opened this issue Jun 5, 2024 · 3 comments
Open
3 tasks done

AT+SYSMSG=0 does not disable WiFi connection related messages #844

BornaBiro opened this issue Jun 5, 2024 · 3 comments
Labels
Status: Awaiting Response awaiting a response from the author

Comments

@BornaBiro
Copy link

Answers checklist.

  • I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
  • I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm currently having an issue with the SYSMSG AT command. As described here setting ATSYSMSG=0 should block all prompt messages from the ESP32 to the master device including the WiFi connection status, but it does not for some reason.

I made a test setup with my phone as a hotspot and ESP32 is connected to my phone. With SYSMSG=0 and ESP32 connected to my phone, I disable the hotspot on my phone and ESP32 immediately sends WIFI DISCONNECTED.

I'm using ESP32-C3 with ESP32 AT Firmware V3.3.0.0 and communication is done with the SPI.

This is a big problem for me since I'm using pass-through mode for getting HTTP GET and HTTP POST.

Here is the AT Command log

-----[SENT]-----
AT+SYSMSG=0
---[SENT END]---
-----[RESPONSE]-----
AT+SYSMSG=0

OK

---[RESPONSE END]---
-----[SENT]-----
AT+SYSMSG?
---[SENT END]---
-----[RESPONSE]-----
AT+SYSMSG?
+SYSMSG:0
OK

---[RESPONSE END]---
-----[SENT]-----
AT+CWINIT=1
---[SENT END]---
-----[RESPONSE]-----
AT+CWINIT=1

OK

---[RESPONSE END]---
-----[SENT]-----
AT+CWMODE=1
---[SENT END]---
-----[RESPONSE]-----
AT+CWMODE=1

OK

---[RESPONSE END]---
-----[SENT]-----
AT+CWJAP="testWiFiNetworkEsp32","esp32WiFiPass"
---[SENT END]---
-----[RESPONSE]-----
AT+CWJAP="testWiFiNetworkEsp32","esp32WiFiPass"

---[RESPONSE END]---
-----[RESPONSE]-----
WIFI CONNECTED

---[RESPONSE END]---
-----[RESPONSE]-----
WIFI GOT IP

OK

---[RESPONSE END]---
-----[SENT]-----
AT+SYSMSG?
---[SENT END]---
-----[RESPONSE]-----
AT+SYSMSG?
+SYSMSG:0
OK

---[RESPONSE END]---
-----[RESPONSE]-----
WIFI DISCONNECT       <<<<<<<This!

---[RESPONSE END]---

Maybe I'm using a wrong command, so any advice would be helpful.
Thanks!

@ustccw
Copy link
Collaborator

ustccw commented Jun 28, 2024

@BornaBiro Hello, you should use AT+SYSMSGFILTERCFG to set up system message filters and enable the filter by AT+SYSMSGFILTER=1. Here is a detailed example.

AT+SYSMSG usually used for Passthrough Mode, you can refer to the parameter explanation under the command for more details. In your case, AT works in Normal Transmission Mode.

@BornaBiro
Copy link
Author

That was exactly what I used as a workaround in the meantime and it worked perfectly.

One this that I noticed with AT+SYSMSGFILTERCFG is, if there is head and tail regex sent as described here for passthrough mode for removing tail and header form the HTTPCGET on every received data, after sending AT+SYSMSGFILTERCFG with it's parameters and waiting for ">", I must send separate SPI transactions for head and tail data, otherwise ESP32 just hangs.

So, if I need to enable filter for the HTTPCGET to remove header and tail from every HTTP data I need to:

  1. Send AT+SYSMSGFILTERCFG=1,18,3\r\n
  2. Wait for response OK\r\n\r\n>
  3. Send ^+HTTPCGET:[0-9]*,
  4. Wait at least 5 milliseconds
  5. Send \r\n$

Is this is intended behavior? Because I did not see anywhere documented that head and tail data must be sent separately with some delay in between.

@ustccw
Copy link
Collaborator

ustccw commented Jul 3, 2024

@BornaBiro This is not the expected behavior. Could you mind providing your log port logs?
i would like to reproduce it next week, maybe.

@ustccw ustccw added the Status: Awaiting Response awaiting a response from the author label Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting Response awaiting a response from the author
Projects
None yet
Development

No branches or pull requests

2 participants