REST architecture expansion

[sergiomarina]

Hi, this is a question on protocol architecture (in particular for ESP32 WROOM).
The present architecture consists of a standard REST developed with IDF v5.0 libraries.
The AP is also an HTTP server and STA(s) plays as HTTP client (both are ESP32 WROOM).
The HTTP server offers an HTML interface to the operator for maintenance tasks.
As per REST architecture the communication is mastered by the HTTP client.
Polling the server with a HTTP GET request on a regular timeframe makes possible to enable backward communication (from server to client)
I need to increase the frequency of these polling messages but HTTP/TCP takes too many resources and I'm wondering how to build a solution that employs lighter protocols (eg ESP-NOW) for a single very light specific handshake sequence partnering the deployed at the present HTTP/TCP REST services.
Can a similar design be possible? In that case, there are already developed example? If so, where can I get them?
In case an extra ("bidirectional") protocol (eg ESP-NOW) can be added to partner with the REST/HTTP/TCP, will the AP be able to autonomously trigger communication to the STA using that protocol? (that would be even a better solution)

Thank you, S.

[ESP_Sprite]

You'd probably want to use something like UDP for this. ESP-NOW isn't forwarded by access points, so you could get into the situation that two devices can talk over REST but not over ESP-NOW.

[sergiomarina]

Hi ESP_Sprite, thank you for the reply. I did not know about ESP_NOW limit.
Looking at "Kconfig.projbuild" I found in the "esp_now_example" (IDF 5,0) I see the following excerpt:
----------------------------------------------
menu "Example Configuration"

choice ESPNOW_WIFI_MODE
prompt "WiFi mode"
default ESPNOW_WIFI_MODE_STATION
help
WiFi mode(station or softap).

config ESPNOW_WIFI_MODE_STATION
bool "Station"
config ESPNOW_WIFI_MODE_STATION_SOFTAP
bool "Softap"
endchoice
--------------------------------------
And the code reports accordingly the following:
--------------------------------------
#if CONFIG_ESPNOW_WIFI_MODE_STATION
#define ESPNOW_WIFI_MODE WIFI_MODE_STA
#define ESPNOW_WIFI_IF ESP_IF_WIFI_STA
#else
#define ESPNOW_WIFI_MODE WIFI_MODE_AP
#define ESPNOW_WIFI_IF ESP_IF_WIFI_AP
#endif
--------------------------------------

that's why I figure out the REST architecture would primarily manage the WiFi configuration (with some minor constraints ESP_NOW would require) and, based on the specific CONFIG parameter here above, I assumed both AP and STA in REST architecture can be overall compatible with ESP_NOW.
I preferred ESP_NOW since 99.9% of the solution exploits TCP suitably so I do not want to modify it.
I only need to address a very tiny and frequent polling message with low priority class.
Being ESP_NOW bi-directional it would nicely simplify the solution, making the (frequent) polling not necessary anymore
Definitely, if I need to keep the REST architecture "unmixed", UDP is the best "option B".
Taking the chance of this exchange, are there alternatives already tested for polling avoiding within a REST architecture?
Thank you
/.




SP_NOW

[sergiomarina]

Hi ESP_Sprite,
hereafter the output I got when I set "Softap" in "menuconfig::

I (735) ESPNOW: espnow [version: 1.0] init
I (5735) espnow_example: Start sending broadcast data
E (5735) espnow_example: Send error
I (5735) ESPNOW: espnow [version: 1.0] deinit

Is that the expected result with such setup?

If so, then
1. the "ESPNOW"'s example included in "IDF 5.0"'s environment can be misleading.
2. ESPNOW is not an option.

Back to UDP.
Are there examples based on the communication with UDP?
I found two examples for "UDP_client" and "UDP_server".
Has the coexistence with "REST HTTP" client(/server) been tested already?
Based on your tip I think so.
According to my understanding the server implements a daemon listening to a defined port so the client can trigger the communication.
Is the related architecture documented somewhere?

Is it possible to program the same ESP32 to act both as "UDP server" and a "REST HTTP TCP client"?
And similarly to act as "UDP client" and "REST HTTP TCP server"?

In the "UDP server"'s readme file I found the following excerpt:
----------------------------------------------
Send UDP packet via netcat
echo "Hello from PC" | nc -w1 -u 192.168.0.167 3333
Receive UDP packet via netcat
echo "Hello from PC" | nc -w1 -u 192.168.0.167 3333
------------- is it correct? or just a typo? ---------

Many thanks!

[sergiomarina]

Hi ESP_Sprite,
the solution with UDP works, but I'm still wondering why ESP32 acting in AP mode cannot run ESP_NOW.
I'm looking in the components folder in release 5.0 and I find everything settle down for the combination
- wifi AP interface and
- ESP_NOW protocol

Here below a short example of what written here above.
1. From header file "esp_now.h"
typedef struct esp_now_peer_info {
uint8_t peer_addr[ESP_NOW_ETH_ALEN]; /**< ESPNOW peer MAC address that is also the MAC address of station or softap */
uint8_t lmk[ESP_NOW_KEY_LEN];
uint8_t channel;
wifi_interface_t ifidx; /**< Wi-Fi interface that peer uses to send/receive ESPNOW data */
bool encrypt;
void *priv;
} esp_now_peer_info_t;

2. From header file "esp_wifi_types.h"
typedef enum {
WIFI_IF_STA = ESP_IF_WIFI_STA,
WIFI_IF_AP = ESP_IF_WIFI_AP,
} wifi_interface_t;

Where am I wrong?
Please let me know.
Thank you.