gmag11 / EnigmaIOT

Secure sensor and gateway platform based on ESP8266 and ESP32
https://gmag11.github.io/EnigmaIOT
MIT License
240 stars 46 forks source link

Limitation on Number of total nodes #22

Closed arihantdaga closed 3 years ago

arihantdaga commented 3 years ago

Please forgive me This is a question not an issue. I read in the Readme that there is no limitation on the number of nodes with EnigmaIot, even when using esp now, how will that be possible? Since 20 nodes is the limit imposed by esp now itself. Is there something special we are doing in this project ? I was looking at the code and i did not see a call to the function esp_now_add_peer in case of esp8266 (Which i saw in espressig esp now guide). Is this how we are lifting that limit by not adding peer, instead directly sending a message with esp_now_send method ?

I am also curious about this, because i started seeing a problem when we are trying to send more than 1 message quickly without a delay, the message won't be sent. and tx_cb is called with status error. I was wondering if we have to put a queue in the espnow_hal also for sending the messages and ensuring delays between every message.

Note: I am using esp8266 gateway and nodes.

G2G2G2G commented 3 years ago

Some good info here, basically as posted "Only the server or controller MAC must be known. When the client sends to the server the clients MAC is known and can be added as peer on the fly. Then the server can send stuff back." ESP-NOW is pretty silly in general with it's MACs, the way enigma implements it is better than how espressif wanted it to be implemented. https://www.reddit.com/r/esp8266/comments/7s6l5a/espnow_do_i_really_have_to_know_the_mac_for/

The limit doesn't really exist since you can add it, reply to it, and delete it. Only the senders need to know a MAC

gmag11 commented 3 years ago

Exactly. ESP8266 esp-now implementation do not need to call esp_now_add_peer before sending or receiving data so it was easy to implement. In the other hand ESP32 DOES require registering a peer to be able to send data addressed to it. So my workaround is registering the peer just before sending data and unregistering after that.

You can check this on https://github.com/gmag11/EnigmaIOT/blob/master/src/espnow_hal.cpp#L115 .

All MAC addresses stuff is managed inside EnigmaIOT library so the limit is only marked by RAM memory. Indeed, there is a hardcoded limit in configuration, but you can increase and check the impact in free heap. It is here: https://github.com/gmag11/EnigmaIOT/blob/master/src/EnigmaIoTconfig.h#L32

gmag11 commented 3 years ago

I am also curious about this, because i started seeing a problem when we are trying to send more than 1 message quickly without a delay, the message won't be sent. and tx_cb is called with status error. I was wondering if we have to put a queue in the espnow_hal also for sending the messages and ensuring delays between every message.

Note: I am using esp8266 gateway and nodes.

Espressif recommends waiting for result callback before sending new esp-now data. I'm not doing that because during my test I did not see any problem even at high messages rates. tx_cb is processed only to check for comms error in order to trigger search for gateway if there are some consecutive errors. This may happen, for instance, if gateway changes its channel due to a WiFi router reconfiguration.

Anyway I recommend using ESP32 gateway as the higher performance will help to run everything smoother.

gmag11 commented 3 years ago

I've been modifying espnow library to fulfil tx_cb requirement. It has been working during test and I do not see any throughput reduction. It will be released in the next version. You can test it using dev branch.