ESP-Now support for ESP32 (and ESP8266)
Re: ESP-Now support for ESP32 (and ESP8266)
For espnow to work with the build above you need both interfaces up, acc to my tests
Re: ESP-Now support for ESP32 (and ESP8266)
Haven't looked into that but I doubt my scripts were using 516 bytes. Moreover, as soon as I activated both STA and AP, everything worked just fine.
My suspicion is that the issue is related to espnowInstance.peers_table being empty. Once I had both interfaces up, peers_table was updated and scripts ran as a charm
Re: ESP-Now support for ESP32 (and ESP8266)
Tried making both STA an AP active and it made no difference to my issue.
Re: ESP-Now support for ESP32 (and ESP8266)
Hi Glenn,
Didn't get an opportunity to get to the repeater for those two tests. However, I have noticed that the message comes from the remote, through the repeater and down to the local the first time the remote is powered-up. Then after that no more messages.
Dave
Didn't get an opportunity to get to the repeater for those two tests. However, I have noticed that the message comes from the remote, through the repeater and down to the local the first time the remote is powered-up. Then after that no more messages.
Dave
Re: ESP-Now support for ESP32 (and ESP8266)
Hi Glenn,
Finally, the rain let-up. Wettest July since records started!
Managed to perform all the tests again as follows:
1) all ESP32 Generic
2) it returns True for the first message after a remote re-boot then always False. The repeater also shows the first message then no more.
3) No
4) did w0.config('ps_mode'), at the repeater, even though not connected to WiFi and got ps_mode = 1.
When I tried sending a message from the repeater to the remote I got:
Error during execution: (-12393, 'ESP_ERR_ESPNOW_NOT_FOUND')
Is ps_mode = 1 at the repeater correct? It seems to know what the local unit is set to.
Something seems to change in the internal configuration at the remote after sending the first
message. Just my "theory".
Finally, the rain let-up. Wettest July since records started!
Managed to perform all the tests again as follows:
1) all ESP32 Generic
2) it returns True for the first message after a remote re-boot then always False. The repeater also shows the first message then no more.
3) No
4) did w0.config('ps_mode'), at the repeater, even though not connected to WiFi and got ps_mode = 1.
When I tried sending a message from the repeater to the remote I got:
Error during execution: (-12393, 'ESP_ERR_ESPNOW_NOT_FOUND')
Is ps_mode = 1 at the repeater correct? It seems to know what the local unit is set to.
Something seems to change in the internal configuration at the remote after sending the first
message. Just my "theory".
Re: ESP-Now support for ESP32 (and ESP8266)
The peers_table is populated by incoming espnow packets. Ie. you have to receive a message from the other device before it shows up in peers_table. The peers_table is mainly used for tracking the RSSI signal of received packets.
Re: ESP-Now support for ESP32 (and ESP8266)
There is no channel 0 in 2.4Ghz wifi. Channel 0 in add_peer()/get_peer() means to use whatever channel the wifi radio is currently set to (ie. Channel 6 in your case). For the details see: https://docs.espressif.com/projects/esp ... red-devicedavef wrote: ↑Mon Jul 25, 2022 3:03 amAnd on the repeater:because local is on channel 6 (WiFi) does that mean e0 is still on channel 0?Code: Select all
e0.add_peer(local)
Re: ESP-Now support for ESP32 (and ESP8266)
It might be a bug. On my devices, I can see the entries in peers_table without setting AP active. BUT, it is only populated for INCOMING messages from the peer (because that is where we get the RSSI values from).mekanixms wrote: ↑Mon Jul 25, 2022 10:50 amIn my prev post I tested with STA active, AP if disabled; same issues with AP enabled and STA active
After further testing, I see that the espnowObject.peers_table is only populated, with the new macs from add_peer, when both AP and STA interfaces are active (STA if can be disconnected but should be active, and of course same channel for all devices on the AP if).
This way it works well, sends the messages without errors.
Question: is this a bug? Shouldn't it work on either one of the interfaces, not necessarily both active in the same time ?
Re: ESP-Now support for ESP32 (and ESP8266)
That error means you forgot to do add_peer() before send() .davef wrote: ↑Tue Jul 26, 2022 11:50 pm1) all ESP32 Generic
2) it returns True for the first message after a remote re-boot then always False. The repeater also shows the first message then no more.
3) No
4) did w0.config('ps_mode'), at the repeater, even though not connected to WiFi and got ps_mode = 1.
When I tried sending a message from the repeater to the remote I got:
Error during execution: (-12393, 'ESP_ERR_ESPNOW_NOT_FOUND')
ps_mode=1 (WIFI_PS_MIN_MODEM) is fine if not connected to wifi (which is OK for the repeater). If it is connected to wifi as well, it is not good.Is ps_mode = 1 at the repeater correct? It seems to know what the local unit is set to.
Something seems to change in the internal configuration at the remote after sending the first
message. Just my "theory".
You might want to try w0.config(ps_mode=network.WIFI_PS_NONE) on the repeater, but it should not make any difference.
If send() returns False on the remote, that means it thinks it has sent the packet fine, but the peer did not respond.
That could be because the packet was not really sent (unlikely - but one cause MIGHT be that the device is underpowered - once the wifi turns on, the device draws more power which can cause issues with the radio) or that the repeater is really not receiving and responding to the message.
If you share your code, I can try it on some of my devices.
Re: ESP-Now support for ESP32 (and ESP8266)
I've just tested the minimalist case of two peers exchanging espnow packets over channel 6 - with no wifi (which is what your remote-repeater case is) and it works fine. I can keep sending messages many times and it works fine. I can also change one device to another channel and send() will return False as expected. I change the other device to the new channel and send() now returns True and the packet is received.