ESP8266 WiFi gateway port for MySensors

[Yveaux]

@A-R said:

can the GatewayESP8266.ino be used to send data from NodeMCU to Ethernet?

How do you plan to connect the wired ethernet to the NodeMCU board?
You could probably connect a W5100 module through SPI, but why bother?

[A R]

@Yveaux I am using W5100. Its a system requirement. I want wifi connectivity with sensors through ESPs but the final data is to be routed through ethernet for security.

[Yveaux]

@A-R But do you use any MySensors parts then?

[A R]

@Yveaux No. I asked a simple question: can the GatewayESP8266.ino be used to send data from NodeMCU to Ethernet? If you have an answer then do reply.

[Yveaux]

@A-R No need to get all grumpy! I'm just trying to understand what you want to achieve, and help you out.
You are posting to a MySensors forum, so I assumed you are using MySensors software in your project.
Answer to your question: No.

[scalz]

@A-R : it depends of what you are connecting to esp8266, you didn't give details. esp8266 lacks of io, so it depends...I think you have not googled?? esp8266 w5100 for instance, you will find things...then if it is to use radio+w5100 with esp8266, sure it's possible but depends of available io...software spi you would have to double io, hardware spi, need manage your cs lines...some work. If it's just esp8266+w5100 there are already things on google...

[Robban]

@rapzak said:

Hi,

I have added som support, where the gateway can upload data to emoncms, transparant to other functions (not fully testet):

in gatewayutil add this in top of file, after the ARDUINO check:

#define EMONCMS

#ifdef EMONCMS
static WiFiClient emon_client;
const char* emon_host = "emoncms.org";  
const int emon_httpPort = 80; 
const int emon_addr_offset = 10;
#endif

---

Change this function to:

void incomingMessage(const MyMessage &message) {
//  if (mGetCommand(message) == C_PRESENTATION && inclusionMode) {
//	gw.rxBlink(3);
//   } else {
//	gw.rxBlink(1);
//   }
   // Pass along the message from sensors to serial line
   serial(PSTR("%d;%d;%d;%d;%d;%s\n"),message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type, message.getString(convBuf));
#ifdef EMONCMS
     if (!emon_client.connect(emon_host, emon_httpPort)) {
      Serial.println("emoncms connection failed");
      }

      emon_client.print(String("GET /emoncms/input/post.json?&node="+ String(message.sender+emon_addr_offset)+"&json={"+String(message.sensor)+":"+message.getString(convBuf)+"}&apikey=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\n"));
      Serial.println(String("GET /emoncms/input/post.json?&node="+ String(message.sender+emon_addr_offset)+"&json={"+String(message.sensor)+":"+message.getString(convBuf)+"}&apikey=XXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\n"));
#endif
} 

It will upload data with NODE ID and Sensor ID from the network, with an offset of emon_addr_offset...

/Rapzak

Are there any one that can help me implement this in the dev version? Have a nodemcu 1-0 and got errors uploading the 1.5 version so i cant use that. Tried to fix it but ended up with the dev version.

[bkenobi]

Can anyone provide the correct wiring for NodeMCU (ESP-12E) to RFM69HW? I have seen several different guides that show connections for RFM69, but there are several different patterns and none have worked so far. Perhaps I didn't get it right, but this is what I've seen and tried:

someburner/esp-rfm69

RFM69->	ESP-12E
MISO	GPIO12
MOSI	GPIO13
SCK		GPIO14
CS/SS	GPIO15
DIO0	GPIO5
VCC		3V3
GND		GND
ANA		<antenna>

halburd/NodeMCU-Gateway

RFM69->	NodeMCU
NSS		GPIO2 (J2P5)
SCK		SCK (J1P9)
MISO	MISO (J1P8)
MOSI	MOSI (J1P6)
DIO0	SS (J1P7)
VCC		3V3
GND		GND
ANA		<antenna>

I've also determined that the following should also be correct, though again, they all don't match.

RFM69	ESP-12E	WEMOS D1	NodeMCUv3
MISO	GPIO12	D6/D12		D6
MOSI	GPIO13	D7/D11		D7
SCK		GPIO14	D5/D13		D5
CS/SS	GPIO15	D10			D8
DIO0	GPIO5	D3/D15		D1

I've also tried to figure out how to use the nRF24L0+ wiring, but that doesn't quite match either. If someone could simply post a working config, I could get some traction on my project.

[bkenobi]

Looking at the different charts, I've located some errors (I think).

Looking at someburner's setup, it looks like he is opting to use software SPI rather than hardware as the ESP pins for SPI are not on GPIO12-15.

Looking at halburd's code, it appears that he's opted to use GPIO2 for slave select and connect the actual SS to DIO0. I'm not clear why this is done, but it seems odd.

I lost the reference to the last chart. It also uses GPIO's for SPI rather than the built-in hardware SPI. The guide in this sketch is only documented for nRF24L01+, so it doesn't match exactly. But, it also uses GPIO 4, 12, 13, 14, 15. It seems odd to use those rather than the SPI pins.

[Mark Swift]

I tried to get the ESP8266 gateway working for 2 weeks but kept getting st=fail at various times. Switching to a serial gateway fixed it straight away? Is this a known issue? Is it perhaps related to having the ESP8266 and the nRF24L01's so close together? BTW, I tied both the normal gateway and the MQTT gateway without much success. The who time I thought it was a radio issue

This was all running on a NodeMCU v1.0.

Mark

[Yveaux]

@Mark-Swift Did you follow the connection in the ESP build guide?
Did you make any changes to the sketch? Which MySensors version did you use and which ESP Arduino version?
Just asking all these questions so we can be of better help.

[Mark Swift]

@Yveaux I believe so, the nNF24L01 is connected to a NodeMCU (I've tried feeding the radio off both the onboard 3.3v and via VIN and a 1117 3.3v regulator (I have caps across the radio GND / VCC).

No changes were made to the sketch - I'm using the latest development build (also on the nodes). I've tried with all of the ESP Arduino board versions, doesn't seem to change anything?

[Yveaux]

@Mark-Swift said:

kept getting st=fail at various times

Now I read over your post again I get the impression that it sometimes works, and sometimes you get st=fail. Is this correct?

[Mark Swift]

Example - I'm sat here right now with one of my nodes and the gateway connected to my Macbook via USB.

When using the serial gateway I get =ok after each item no problem; in fact I can't make it fail.

When using the ESP8266 MQTT gateway I get:

Starting repeater (RNNRA-, 2.0.0-beta)
Radio init successful.
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,st=ok:R+M+L+T+D+Rpt
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.1
send: 3-3-0-0 s=1,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=2,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=3,c=0,t=16,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=4,c=0,t=15,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=10,c=0,t=1,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=11,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=12,c=0,t=23,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok:

send: 3-3-0-0 s=255,c=0,t=18,pt=0,l=10,sg=0,st=fail:2.0.0-beta
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
Init complete, id=3, parent=0, distance=1
Moisture Sensor: 0
send: 3-3-0-0 s=1,c=1,t=16,pt=2,l=2,sg=0,st=ok:0
Rain Sensor: 0
send: 3-3-0-0 s=2,c=1,t=16,pt=2,l=2,sg=0,st=ok:0
LUX: 54612
send: 3-3-0-0 s=3,c=1,t=37,pt=3,l=2,sg=0,st=ok:54612
Distance: 0 cm
send: 3-3-0-0 s=4,c=1,t=13,pt=2,l=2,sg=0,st=ok:0
No rain or moisture detected, landroid is not waiting: Status(0)
Landroid is free to go and is now waiting on the schedule: Status(0)
Landroid is home charging!
Sending landroidHome (1) status to gateway: send: 3-3-0-0 s=10,c=1,t=16,pt=1,l=1,sg=0,st=ok:1
Sending landroidWaitingTriggered (0) status to gateway: send: 3-3-0-0 s=11,c=1,t=16,pt=1,l=1,sg=0,st=ok:0
Sending timeElapsed (0) status to gateway: send: 3-3-0-0 s=12,c=1,t=48,pt=2,l=2,sg=0,st=fail:0

Using the serial gateway on a nano (Not connected to anything, just the nano and nRF24L01) I get:

Starting repeater (RNNRA-, 2.0.0-beta)
Radio init successful.
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,st=ok:R+M+L+T+D+Rpt
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,st=ok:1.1
send: 3-3-0-0 s=1,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=2,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=3,c=0,t=16,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=4,c=0,t=15,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=10,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=11,c=0,t=1,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=12,c=0,t=23,pt=0,l=0,sg=0,st=ok:
send: 3-3-0-0 s=255,c=3,t=15,pt=0,l=2,sg=0,st=ok:

send: 3-3-0-0 s=255,c=0,t=18,pt=0,l=10,sg=0,st=ok:2.0.0-beta
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=ok:0
Init complete, id=3, parent=0, distance=1
Moisture Sensor: 0
send: 3-3-0-0 s=1,c=1,t=16,pt=2,l=2,sg=0,st=ok:0
Rain Sensor: 0
send: 3-3-0-0 s=2,c=1,t=16,pt=2,l=2,sg=0,st=ok:0
LUX: 54612
send: 3-3-0-0 s=3,c=1,t=37,pt=3,l=2,sg=0,st=ok:54612
Distance: 69 cm
send: 3-3-0-0 s=4,c=1,t=13,pt=2,l=2,sg=0,st=ok:69
No rain or moisture detected, landroid is not waiting: Status(0)
Landroid is free to go and is now waiting on the schedule: Status(0)
Landroid is out cutting the grass!
Sending landroidHome (0) status to gateway: send: 3-3-0-0 s=10,c=1,t=16,pt=1,l=1,sg=0,st=ok:0
Sending landroidWaitingTriggered (0) status to gateway: send: 3-3-0-0 s=11,c=1,t=16,pt=1,l=1,sg=0,st=ok:0
Sending timeElapsed (0) status to gateway: send: 3-3-0-0 s=12,c=1,t=48,pt=2,l=2,sg=0,st=ok:0

[Yveaux]

@Mark-Swift It does work sometimes, so that rules out a lot of possible problems!
How do you power the NodeMCU & rest of the hardware?
Both NodeMCU & nRF are very sensitive to low/noisy supplies.

[Mark Swift]

@Yveaux I power the NodeMCU from either my Macbook Retina, or from a decent USB wall plug, tbh, it seems to make little difference which I use. I presume everyone else is powering them via the USB also?

I've also tried a spare NodeMCU and a bunch of radios. In fact, I've been trying to get this working for 3 weeks, it's literally going to cause a divorce soon

[Yveaux]

@Mark-Swift The log mentions Moisture Sensor, Rain Sensor, LUX, Distance.
Are these real sensor connected (and yes, how) or virtual?

[Mark Swift]

@Yveaux real sensors connected to my robot mower garage node...

[Mark Swift]

@Yveaux Node code is here for reference:

http://pastebin.com/mxkLq1Rp

[Yveaux]

@Mark-Swift To be frank: I don't know.
I'm quite sure it has nothing to do with the ESP port, or software in general.
You could try different orientation of the nRF, or move it closer to the sensor(s).

Are you using an amplified nRF24 btw?

[Mark Swift]

@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]

@Mark-Swift I always use my sniffer in this case to see what's going on on air, but I don't know if your marriage will survive another sniffer build

[Mark Swift]

@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!

[Mark Swift]

@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]

@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.

[hek]

What adjustments do you propose to the MQTT sketch/driver?

[Yveaux]

@hek I'm not familiar with the exact implementation at the moment. Just hoped you would have a hunch where these issues might arise from or how we can prevent them...

[hek]

Nope, I don't get why baud rate would affect radio/tcp traffic. Maybe @Mark-Swift could shed some light on it.

[robosensor]

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

[hek]

Hmm.. blocking code.. crap.

[robosensor]

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 of gw.wait() and so on.

[Yveaux]

@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.

[hek]

Yes, at least for the gateway and repeaters this would be preferred. How's your play-time-bandwidth?

[Yveaux]

@hek said:

How's your play-time-bandwidth?

I already feared you we going to ask this
Quite limited at the moment, but such things should grow in my mind first. Let's start with that hehe..

[hek]

Mo ha haha

[scalz]

@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 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
very tricky issue to debug when so much layers..

[robosensor]

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.

[Yveaux]

@robosensor I think message buffering could be the first step to (more) reliable delivery.

[scalz]

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

[Yveaux]

@scalz Thanks for the links man!

Now we're at it: anyone knows if a blocked socket connection can be interrupted at all by an external pin interrupt on ESP(Arduino) ? Otherwise buffering on interrupts will make no sense...

[Mark Swift]

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!?

[Yveaux]

@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...

[Mark Swift]

@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...

[Mark Swift]

@Yveaux Is there a way I can track dropped messages?

[Yveaux]

@Mark-Swift my queueing code counts how many messages could not be stored due to the queue being full, and therefore got lost. If the radio drops messages because it's FIFO is full we won't know...

[Mark Swift]

@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]

@Mark-Swift Sorry, my bad. This is AVR only code... Have to look for the ESP equivalent...

[Yveaux]

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...

[Mark Swift]

nightmare!

Let me know how you get on...

[signal15]

Is anyone having luck running the ESP without problems at all? I'm on 1.5 and it's my first gateway, and I cannot get sensors to include. Should I try the development branch? Or, should I build a different gateway altogether? I just need something that works at this point.

[alexsh1]

Let me reiterate what @signal15 asked - did anyone successfully have esp8266 running as the GW on 2.0b? I have just acquired Wemos mini and would like to try it

[Anduril]

@alexsh1 @signal15 I can confirm that the ESP gateway is working fine and stable. I even enabled the ESP OTA update function and that's working fine too.

[signal15]

@Anduril

Can you point me to documentation on how the OTA update stuff works and what the capabilities are?

[Anduril]

@signal15 well there is a doc about OTA here. I discussed this topic with tekka, who is the author of the GatewayESP8266OTA example in the mysensors lib here.
It took me some time to get this working, but now I can upload new firmware to my ESP using wifi. Only drawback is that is seems to be not compatible with the mqtt version of the gateway. At least I was not able to get this working and stopped on that.
If you have further questions, don't hesitate to ask.

[marceloaqno]

I recently built a mysensors node with esp8266 where I needed many I/O pins which made me realize the possibility of using the pin RX (http://www.forward.com.au/pfod/ESP8266/GPIOpins/ESP8266_01_pin_magic.html).
Initializing the serial with:

Serial.begin(MY_BAUD_RATE, SERIAL_8N1, SERIAL_TX_ONLY, 1);

allows to use RX pin for I/O.

So I was wondering if it would be useful to add a way in which the serial port can be initialized:

#define MY_SERIAL_MODE SERIAL_TX_ONLY
#define MY_SERIAL_MODE SERIAL_RX_ONLY
#define MY_SERIAL_MODE SERIAL_FULL   (default)

github.com/marceloaqno/MySensors/commit/687fecc6b4abb782eae8e1abb3b07016bfeac291

Also, to use the esp8266 analog pin, I had to comment the line:

ADC_MODE(ADC_VCC);

from MyHwESP8266.cpp.
Is there another way to use analog readings without messing the code?

Excellent port by the way, I have been using here and it works great!!

[Mark Swift]

Was the blocking code issue ever resolved @Yveaux ?

[Yveaux]

@Mark-Swift no, still open at Esp side, and I couldn't think of a clean way working around it...

[gloob]

I have an ESP using as a gateway and want to send some sensor information each 5 minutes to the controller.

Is it possible to use the wait command in the "loop"?

void loop() 
{
  wait(unsigned long ms);
  statusCounter += 1;
  send(msg.set(statusCounter));
}

[mfalkvidd]

@gloob yes

[gloob]

Thanks for the answer. So all incoming or outgoing messages of the gateway will be processed in the background, while the "wait" command is active?

[hek]

@gloob Yes

[Eawo]

Hey

Im not really getting it is this a gateway for mysensors nodes or for mtqq Nodes with esp stuff? I dont really getting it. Do you need a esp8266 wifi gateway to get a wireless gateway for mysensors stuff or is like. Mysensors gateway ---> Esp8266 gateway --- Esp8266 node.

Sorry i dont really understand but im intressted in buying 8-10 sonoff for my window lamps, and i want them to work with domoticz

[alexsh1]

@Eawo the sonoff does not require any GW to work with Domoticz.

[hek]

Yes, @alexsh1 is right. You would normally setup ESP nodes (like the sonoff) to act as a gateway, communicating directly with the controller themselves.

But if you're persistent (or have short wifi range), you can get two ESP nodes to communicate with each other using NRF24/RF69 like @mfalkvidd did recently.

[Matthew Ohlson de Fine]

Hi. I have loaded the Sonoff as an Ethernet gateway using the modified sketch in Vera and it recognizes it perfectly. The problem I have is that I dont know how to control the relay with the Vera now. Please help.

[Mark Swift]

@hek @Yveaux I see the blocking issue on the ESP side has been closed... Does this mean we can now use the ESP in high traffic environments? How can we test it, I assume we also need to activate IRQ for the NRF in the ESP gateway code?

[Yveaux]

@Mark-Swift that issue apparently addressed an issue in the vs1053 library, which surfaced because the esp8266 doesn't support interrupts on spi transfers.
The issue was closed because the vs1053 library was modified to support esp8266, unfortunately not because esp interrupt support for spi was implemented...

[Mark Swift]

@Yveaux said in ESP8266 WiFi gateway port for MySensors:

@Mark-Swift that issue apparently addressed an issue in the vs1053 library, which surfaced because the esp8266 doesn't support interrupts on spi transfers.
The issue was closed because the vs1053 library was modified to support esp8266, unfortunately not because esp interrupt support for spi was implemented...

@Yveaux You're right, should have read more before jumping to conclusions

Damn, I thought I could finally dump my serial gateway!

[ahmedadelhosni]

Is it normal to use GPIO15 ? Isn't it used for booting mode ?

[mfalkvidd]

@ahmedadelhosni where is gpio15 used? (This is a very long thread so finding it without your help isn't easy)