ESP8266 WiFi gateway port for MySensors
-
The problem is slightly wider than it seems. Wireless messages should be fetched from internal NRF24 FIFO and stored into memory as soon as possible (using interrupts?). But lack of RAM makes the problem difficult to be solved.
The same thing happens not only with ESP8266 gateway and TCP ACKs, but also with all blocking calls during sensor reading (for example for old blocking call to read DS18B20 data with 750ms delay), with improper use of
delay()instead ofgw.wait()and so on. -
The problem is slightly wider than it seems. Wireless messages should be fetched from internal NRF24 FIFO and stored into memory as soon as possible (using interrupts?). But lack of RAM makes the problem difficult to be solved.
The same thing happens not only with ESP8266 gateway and TCP ACKs, but also with all blocking calls during sensor reading (for example for old blocking call to read DS18B20 data with 750ms delay), with improper use of
delay()instead ofgw.wait()and so on.@robosensor said:
lack of RAM
Not really an issue on ESP I would say.
@hek IMHO it really is time to investigate the impact on the library to support message queueing (fetched & sent from interrupt).
Starting with @tekka rewrite of the nRF driver in 2.0 beta, as it supports SPI transactions.
Probably we can add support incrementally to lower the impact on the library. -
Yes, at least for the gateway and repeaters this would be preferred. How's your play-time-bandwidth?
-
@hek @Yveaux : I don't know if this could help. but some times ago I found a lib when you were talking about this issue but I have never had enough time to test it. It is a "non blocking" ack with some buffering version for wifiserver. I think that does not solve completely the buffering issue :confused: But maybe a small step..
I don't remember where I read this but igr was saying it would be better to have a lib for this than modifiying the wifiserver lib for compatibility with other arduino wifi libs. So maybe this guy did it.
http://www.forward.com.au/pfod/pfodParserLibraries/index.html
In the middle :)
I also read that for esp, bigger tcp packet were processed faster than small :open_mouth:
very tricky issue to debug when so much layers.. -
Also it is possible to partially solve this issue by fetching all available messages from NRF24 FIFO and concatenating them into one TCP packet for ESP. It is possible that this will be useful for other gateways too.
@Yveaux said:
IMHO it really is time to investigate the impact on the library to support message queueing (fetched & sent from interrupt).
But no chances that MYS protocol will be changed? I'm talking about reliable delivery and message ids. That topic is very close to this.
-
Also it is possible to partially solve this issue by fetching all available messages from NRF24 FIFO and concatenating them into one TCP packet for ESP. It is possible that this will be useful for other gateways too.
@Yveaux said:
IMHO it really is time to investigate the impact on the library to support message queueing (fetched & sent from interrupt).
But no chances that MYS protocol will be changed? I'm talking about reliable delivery and message ids. That topic is very close to this.
-
this was the thread I read. pfod lib creator and esplibs team were talking about this.
https://github.com/esp8266/Arduino/issues/1430
And it seems there is another lib too for this:
https://github.com/me-no-dev/ESPAsyncTCP -
this was the thread I read. pfod lib creator and esplibs team were talking about this.
https://github.com/esp8266/Arduino/issues/1430
And it seems there is another lib too for this:
https://github.com/me-no-dev/ESPAsyncTCP -
Thanks for looking into this guys... I've been doing some tests and basically the ESP gateway is not an option for me right now due to too many radio failures.
Using the normal serial gateway I tested one of my nodes that sends about 15 values during each loop; it was perfect every time!
The same test with the ESP shows failures every few messages or so, introducing a large radio delay between each send fixes it, but the issue can still occur if other nodes call in at the same time.Another interesting thing, when I don't specify a gateway, or static IP I get no failures, when I do, I get failures, what!?
-
Thanks for looking into this guys... I've been doing some tests and basically the ESP gateway is not an option for me right now due to too many radio failures.
Using the normal serial gateway I tested one of my nodes that sends about 15 values during each loop; it was perfect every time!
The same test with the ESP shows failures every few messages or so, introducing a large radio delay between each send fixes it, but the issue can still occur if other nodes call in at the same time.Another interesting thing, when I don't specify a gateway, or static IP I get no failures, when I do, I get failures, what!?
@Mark-Swift Don't know if you already ditched the ESP gateway completely, but you could give my latest experiment a try: https://github.com/Yveaux/Arduino/tree/development
It adds a reception queue to the gateway which will immediately retrieve a message from the radio when it comes in. This process should even continue when the ESP is blocked on some TCP transfer.
Only thing you have to do is connect the IRQ line from the nRF radio to the ESP (e.g. to pin 1), and define the IRQ pin at the top of your gateway sketch:#define MY_RF24_IRQ_PIN (1)I tested this on a UNO, and can easily sleep the gateway for 1 second or more when messages come in at 0.1sec interval -- none gets lost. The buffer is set to 20 by default, but you can increase it when the amount of RAM allows it:
#define MY_RF24_MESSAGE_BUFFER_SIZE (50)I don't have a NodeMCU setup ready so I cannot test it on ESP myself...
-
@Yveaux I'll sure give it a shot when time allows, most likely tomorrow... I've actually worked around the issue by using a regedit hack on my Windows server to remove the 200ms TCP delay. I also fried a Node MCU tonight due to frustration and not concentrating!
Thanks for the efforts, sounds a great solution :)
BTW, I figured out my main issue was trying to put the nRF24l01+PA+LNA and ESP in a small project box, I guess that also causes issues, especially with the crappy cheap unshielded PA modules (I'm awaiting a proper shielded version).
@robosensor also...
-
@Yveaux Is there a way I can track dropped messages?
-
@Yveaux I just tried to compile it and get the following error:
In file included from /Users/markswift/Documents/Arduino/libraries/MySensors/core/MyTransportNRF24.cpp:23:0,
from /Users/markswift/Documents/Arduino/libraries/MySensors/MySensor.h:260,
from /Users/markswift/Documents/Personal/Hobbies/Arduino/GatewayESP8266MQTTClient/GatewayESP8266MQTTClient.ino:132:
/Users/markswift/Documents/Arduino/libraries/MySensors/drivers/CircularBuffer/CircularBuffer.h:23:25: fatal error: util/atomic.h: No such file or directory
#include <util/atomic.h> -
@Yveaux I just tried to compile it and get the following error:
In file included from /Users/markswift/Documents/Arduino/libraries/MySensors/core/MyTransportNRF24.cpp:23:0,
from /Users/markswift/Documents/Arduino/libraries/MySensors/MySensor.h:260,
from /Users/markswift/Documents/Personal/Hobbies/Arduino/GatewayESP8266MQTTClient/GatewayESP8266MQTTClient.ino:132:
/Users/markswift/Documents/Arduino/libraries/MySensors/drivers/CircularBuffer/CircularBuffer.h:23:25: fatal error: util/atomic.h: No such file or directory
#include <util/atomic.h> -
This util/atomic.h is an easy fix, but then the next error occurs: current ESP8266 Arduino port (even tried upto 2.2.0) does not support SPI access from within interrupts (SPI.usingInterrupt is not supported.
See https://github.com/esp8266/Arduino/issues/1943.
This means I cannot reliably get the message data from the nRF from within an interrupt on ESP8266, using the regular Arduino SPI library.
Have to think if there's another solution (or push this issue to be solved ;-) )
To be continued... -
nightmare!
Let me know how you get on...
