ESP8266

[jgracio]

Works perfectly on atmelavr but I'm not being able to get reading from the same radio on an ESP8266 platform (wemos d1). Can you please help me with this?

[dgomes]

Have a look at https://github.com/dgomes/homeGW/issues/1

[jgracio]

Thanks for your prompt reply My arduino/esp8266 knowledge is not deep enough to understand #1. Do i have to replace function setup on homegw.ccpp file?

bool HomeGW::setup(uint8_t pin) { HomeGW::pin = pin; pinMode(pin, INPUT); digitalWrite(pin, LOW); attachInterrupt(pin, HomeGW::handleInterrupt, CHANGE); // 1 = PIN3 return true; }

[dgomes]

Just add your questions to the other thread, maragelis will probably answer you. Personally I don't run this code on ESP8266.

[jgracio]

Obrigado

[chinswain]

@jgracio I made a quick fork + change for my testing on an esp32, should work on ESP8266.

https://github.com/chinswain/homeGW

[JLNapo]

Hello, I use your library for Digoo R8H and R8S probes with a Lolin ESP8266 (Chinese) If I use your library for a test, no problem, but if I use with other hardware, the ESP8266 reboots all the time. I use I2C and OneWire for the different devices (Screen, MCP23008, DS18B20 etc ...) and RXB6 (3.3v) for the 433Mhz. I also use HTTP and OTA. Everything works, and suddenly the reboot processor. I unplug the data and the program runs, I plug the data again and a few moments after a few correct receptions, reboot again. And so on. I decoded the reboot message and said that there is a problem in "plugins.cpp:31" and "homeGW.cpp:87" I do not know how to fix the problem. For the weather plugin that I use with DG-R8S you have to divide by 2 the temperature and humidity result, otherwise it's wrong. But that does not matter with reboot. Thanks for helping me, and I think it will help other users as more and more people are using Digoo probes. Best regards, Jean-Luc P.S. Pardon for my English who is not my first language.

[dgomes]

it's rebooting on interrupt handling, as I said before in this thread I don't use this code with an ESP8266 and can't therefore help debugging :(

[JLNapo]

Hello, Thank you very much for the answer, even if it does not help me. Thank you also for your sharing, if you have a track, thank you for telling me which one to follow. Best regards, Jean-Luc

[jgracio]

Some time ago my sketch started failing to start returning error "ISR not in IRAM". I reverted the esp9266 library to the previous version and now all works fine: Using Arduino IDE you have to load version 2.5.0 instead of 2.5.1 and on PIO I changed the platform on platformio.ini to "platform = espressif8266@2.0.4"

[JLNapo]

Hello, Overall the same mistake : "ISR not in IRAM" Thank you for this information, I will try, otherwise I have a plan B by deporting on another ESP8266 the function of temperature concentrator with HTTP server, I started a test and it works by modifying the library like this "void ICACHE_RAM_ATTR HomeGW :: handleInterrupt () {". But only if there is only that in the ESP because it does not work with my first system. Thank you again, I will try anyway. @ + Jean-Luc

[JLNapo]

I bring you the result of my tests: It does not work, with or without ICACHE_RAM_ATTR by setting up version 2.5.0 of ESP8266. My Arduino IDE is 1.8.9 maybe it does. I will not try everything, I will try a library that gave me satisfaction but did not treat the model R8H, only R8S. If I try to modify it to have also R8H I could not have any reboot, but it's not won especially in the library I'm not at the top.

[timmpo]

This is a verry nice app :) good job!

when i use this with esp8266 with wifi and webserver enabled i must detachInterrupt before esp do a server.send and then attachInterrupt again, same when i do a bigger serial.print.

please add a simple detachInterrupt function in homeGW.cpp

some info: https://www.esp8266.com/viewtopic.php?f=160&t=18679

Two things to keep in mind:

The WiFi-stack is the most important process of an ESP: if you neglect it (giving it not enough time to do its work) it will reset your ESP. Interrupts need to be as short as possible: actually only setting (or increasing) some global variables and not much more. No reading or writing to WiFi or serial (these also use interrupts), no delays and no (long) loops

Following the second rule we can only crunch numbers (like determining the frequency output by the module) and act upon this in the main loop, not forgetting to regularly yield() the WiFi stack as stated in the first rule.

To follow up on that first rule: if the WiFi process needs too much processor time, that's just hard luck for the main loop: the WiFi stack always has precedence over everything else.

[dgomes]

thank you @timmpo

As I've said before, I use this code with Arduino not with ESP (years with no issues), but if you find a way to improve the code base for the ESP I will gladly accept a Pull Request!

Best Regards