ESP8266 RFM69 gateway
-
@korttoma said:
I think I miss understood you a bit. I thought your ESP/RFM69 gateway did not work att all but you meant that the local WebServer did not work right?
The RFM69/ESP8266 have been working very well, since I started using the "real" PCB instead of the breadboard. As for the webserver feature - it does not work for me, when using RFM69 radios. I'm currently trying to find out what's happening
- Jan
-
@chrille so I tried the WebServer according to the instructions given by @Japio.
My Gateway is still working and the WebPage shows up but only the Gateway messages sent counter is increasing.
The Gateway messages received value remains zero.
"Running for" value seems to be working.I also added the lines you suggested about the Free memory and WiFi signal and I see:
Free memory: 40456 bytes
WIFI signal: -77dBmAnything else I can try?
-
@chrille nice ;) a little advice if you're ok, that would have been better if you had nothing under your esp8266 antenna (no routes or gnd plane near the ant).
-
@chrille nice ;) a little advice if you're ok, that would have been better if you had nothing under your esp8266 antenna (no routes or gnd plane near the ant).
-
Thanks @Yveaux for looking in to the code. From your post, l am not sure if I should get both tx an rx counts in my setup since I am not using MQTT or serial GW. I have just the ESP/RFM69 gateway an one sensebender sending data. Later when I checked I noticed that the other counter had actual increased also. I need to get another node implemented to my test system to test further but I don't have any more RGM69 modules at the moment.
-
@chrille nice ;) a little advice if you're ok, that would have been better if you had nothing under your esp8266 antenna (no routes or gnd plane near the ant).
@scalz said:
@chrille nice ;) a little advice if you're ok, that would have been better if you had nothing under your esp8266 antenna (no routes or gnd plane near the ant).
If I make a new board to add support for the 3-pin version of the ATSHA204 and fix the swapped SCL/SDA pins I will take this into account. Thanks for the comment.
(I guess the best solution if I want to extend wifi coverage would be to use at ESP-07 with an external antenna - however I don't have issues with wifi coverage for the gateways with my current setup)- Jan
-
Thanks @Yveaux for looking in to the code. From your post, l am not sure if I should get both tx an rx counts in my setup since I am not using MQTT or serial GW. I have just the ESP/RFM69 gateway an one sensebender sending data. Later when I checked I noticed that the other counter had actual increased also. I need to get another node implemented to my test system to test further but I don't have any more RGM69 modules at the moment.
@korttoma said:
From your post, l am not sure if I should get both tx an rx counts in my setup since I am not using MQTT or serial GW. I have just the ESP/RFM69 gateway an one sensebender sending data. Later when I checked I noticed that the other counter had actual increased also. I need to get another node implemented to my test system to test further but I don't have any more RGM69 modules at the moment.
Could try changing
if (indication) { indication(ind);to
sleep(10); if (indication) { indication(ind);in MyIndication.cpp (almost in the bottom of file) - it works for me! - although I have no idea why
-
@korttoma said:
From your post, l am not sure if I should get both tx an rx counts in my setup since I am not using MQTT or serial GW. I have just the ESP/RFM69 gateway an one sensebender sending data. Later when I checked I noticed that the other counter had actual increased also. I need to get another node implemented to my test system to test further but I don't have any more RGM69 modules at the moment.
Could try changing
if (indication) { indication(ind);to
sleep(10); if (indication) { indication(ind);in MyIndication.cpp (almost in the bottom of file) - it works for me! - although I have no idea why
-
@chrille that doesn't seem to make sense.
Sleep will power down the mpu, sending even more indications (sleep & wake up).
The library is not reentrant, so expect erroneous behavior using your change!@Yveaux said:
Sleep will power down the mpu, sending even more indications (sleep & wake up).
The library is not reentrant, so expect erroneous behavior using your change!I fully agree that it does not make sense! It just seems that a slight delay is required - see my comments in issue #584 - just adding a couple of lines of serial debug is also sufficient. Also, I do not propose this is as a permanent fix, but hopefully my observations can help someone with a better knowledge of the codebase to narrow down the real issue
For now the code behaves as expected and looking at my serial console I do not get any additional indication calls because of this
- Jan
-
@Yveaux said:
Sleep will power down the mpu, sending even more indications (sleep & wake up).
The library is not reentrant, so expect erroneous behavior using your change!I fully agree that it does not make sense! It just seems that a slight delay is required - see my comments in issue #584 - just adding a couple of lines of serial debug is also sufficient. Also, I do not propose this is as a permanent fix, but hopefully my observations can help someone with a better knowledge of the codebase to narrow down the real issue
For now the code behaves as expected and looking at my serial console I do not get any additional indication calls because of this
- Jan
-
@chrille Maybe I'm lost because of the split of the topic, but can you summarize what problem you actually solve by adding an extra delay?
@Yveaux said:
Maybe I'm lost because of the split of the topic, but can you summarize what problem you actually solve by adding an extra delay?
Yes, the issue is missing callbacks to the indication() function
To verify I add a simple indication() function in my gateway sketch, that prints the indication type to the serial console. When running on an ESP8266/NRF24 gateway it works as expected. When running on an ESP8266/RFM69 gateway only some events generates the callback
For instance type 11 (client connect) generates a callback but type 2 and 3 (RX and TX) does not. However type 2 and 3 events does trigger the function to flash the corresponding LED's on my gateway, and the calls to the LED flashing and the indication() function, both happens within MyIndication.cpp. By introducing a small delay right before the indication call, suddenly all events generates the indication() call. The delay can be created by writing debug info to the serial console or sleep()'ing for 10 ms.
(Arduino 1.6.11 and latest MySensors beta)
Maybe we should continue in the comments section of the issue I created for this?
-
@Yveaux said:
Maybe I'm lost because of the split of the topic, but can you summarize what problem you actually solve by adding an extra delay?
Yes, the issue is missing callbacks to the indication() function
To verify I add a simple indication() function in my gateway sketch, that prints the indication type to the serial console. When running on an ESP8266/NRF24 gateway it works as expected. When running on an ESP8266/RFM69 gateway only some events generates the callback
For instance type 11 (client connect) generates a callback but type 2 and 3 (RX and TX) does not. However type 2 and 3 events does trigger the function to flash the corresponding LED's on my gateway, and the calls to the LED flashing and the indication() function, both happens within MyIndication.cpp. By introducing a small delay right before the indication call, suddenly all events generates the indication() call. The delay can be created by writing debug info to the serial console or sleep()'ing for 10 ms.
(Arduino 1.6.11 and latest MySensors beta)
Maybe we should continue in the comments section of the issue I created for this?
-
@chrille at least issue https://github.com/mysensors/MySensors/issues/585 (missing rx indications) has been solved in development.
-
@chrille the fact that it works for nrf24, but not for rfm69 seems very strange as there are no indication-related calls in either radio code.
The gw_rx and gw_rx indications are generated for valid message exchange on the gateway interface (Ethernet, serial, mqtt), while regular TX and rx indications are for valid message exchange by the connected radio (nrf24, rfm69).
