Open ximon opened 4 years ago
I'm certainly no expert but I would think that option 3 is the cleanest solution as one $5 dev board can then handle everything. Option 1 and 2 looks like unnecesseswary development with Option 1 looking like a a bodge. Seems like the 8266 is being phased out anyway. Tiny bonus, you could potentially use the esp32 internal temperature sensor to monitor outside temp (after calibrating with an offset.)
Esp32 was my last choice purely because I was determined to get this running perfectly on the esp8266 but it's been plagued with problems since I started the project - I think it's down to the frequency of the interrupts.
I have a couple of esp32 dev boards spare I'll do some testing with and see how things go. Hopefully it'll be as simple as having WiFi on one core and everything else on the other, I haven't looked deeply into the ulp but it from what I have heard it sounds like an ideas choice for decoding.
Pretty sure the IRRemote library does its receiving/decoding from a function called in loop, works perfectly at the low message rates I have used it for - could be a simple solution with not a lot of effort.
ESP8266 seem to struggle with high demand things theses days. I remember when the ESP32 was a luxury board to use - seems like it's becoming the go-to board now unless you have something simple with limited pins etc.
I'll branch the current esp8266 code and make another branch for the esp32, once confirmed it's working i'll merge the esp32 code into main and leave the esp8266 for reference.
Everything seems to be really unstable with multiple restarts happening often, also pin change interrupts seem to miss some transitions and mess with the message receiving. This seems to have increased since moving to timer and interrupt driven message decoding.
Current options for this, in order of preference:
Anyone have any thoughts / suggestions / tips?