ESP8266 WiFi gateway port for MySensors
-
@Yveaux Node code is here for reference:
-
@Yveaux That's a shame, I'd really like to solve this. I've tried the radios orientated different ways but it makes little difference. Not using a PA+LNB, I was but gave up on it as I thought it was the issue (Now realise it wasn't).
Strange that I only see these issues with the ESP, and as soon as I switch to a Nano running the serial gateway they're gone.
-
@Yveaux That's a shame, I'd really like to solve this. I've tried the radios orientated different ways but it makes little difference. Not using a PA+LNB, I was but gave up on it as I thought it was the issue (Now realise it wasn't).
Strange that I only see these issues with the ESP, and as soon as I switch to a Nano running the serial gateway they're gone.
-
@Yveaux I doubt it will, seems I'm destined to build a serial gateway, crap, I've invested so much time in this and tried everything!
-
@Yveaux
How about this, for a laugh I just tried rolling the ESP8266 gateway back to v1.5 (master).Guess what? It works every time with no fails (communicating with my 2.0.0 beta node). So the issue lies with the latest development version somewhere, any ideas?
~~
Insane, I just took the gateway down the other end of the house and not one fail, wow! So okay, what was changed in version 2.0.0?UPDATE: After more investigation, the reason it was working is because v1.5 only has a straight forward gateway version, and until now I've been using the MQTT client. It seems the gateway versions work fine, but the MQTT client version create the fails!UPDATE 2: Okay, I can reproduce the fails with the gateway too, let me try and explain. When the gateway is not connected to anything (for example Domoticz) I get OK all of the time, no fails whatsoever. If I connect to Domoticz, I start to get fails against certain child sensors (it's always the same!). I presume it's sketch related, or even the amount of node updates I'm sending? As I believe the fails are the same I'm seeing with the MQTT client.
UPDATE 3: Nearly 3 weeks in and I've just figured out what has been causing me all this pain. I've always commented out the default 9600 serial baud define on the ESP8266 sketches. It seems this combined with the 200ms TCP delay has been causing me my issues when connecting to my Windows 7 machine. S$%&*!
-
@Yveaux
How about this, for a laugh I just tried rolling the ESP8266 gateway back to v1.5 (master).Guess what? It works every time with no fails (communicating with my 2.0.0 beta node). So the issue lies with the latest development version somewhere, any ideas?
~~
Insane, I just took the gateway down the other end of the house and not one fail, wow! So okay, what was changed in version 2.0.0?UPDATE: After more investigation, the reason it was working is because v1.5 only has a straight forward gateway version, and until now I've been using the MQTT client. It seems the gateway versions work fine, but the MQTT client version create the fails!UPDATE 2: Okay, I can reproduce the fails with the gateway too, let me try and explain. When the gateway is not connected to anything (for example Domoticz) I get OK all of the time, no fails whatsoever. If I connect to Domoticz, I start to get fails against certain child sensors (it's always the same!). I presume it's sketch related, or even the amount of node updates I'm sending? As I believe the fails are the same I'm seeing with the MQTT client.
UPDATE 3: Nearly 3 weeks in and I've just figured out what has been causing me all this pain. I've always commented out the default 9600 serial baud define on the ESP8266 sketches. It seems this combined with the 200ms TCP delay has been causing me my issues when connecting to my Windows 7 machine. S$%&*!
@Mark-Swift Well, look on it from the bright side: your marriage is saved now :bowtie:
There have been more reports from issues with connections to external servers (e.g. MQTT, Domotiocz) that take too long.
Maybe we should pull @hek in as he wrote the MQTT client for ESP. -
ESP8266 gateway is quite unusable in setups where TCP ACKs can be delayed. This is because thread is blocked until TCP ACK received in ESP wifi code. So all wireless messages will be rejected if NRF24 receives more than 3 messages during this 200ms delay: http://forum.mysensors.org/topic/1870/esp8266-wifi-gateway-port-for-mysensors/235
-
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
