I’m currently developing some custom multilevel sensor projects for a student science lab, and I’ve come across a rather odd problem and was wondering if anyone has experienced this (BTW, I’m still digging though the code to find the bug. Code compiles with NO errors or warnings).
The design uses a clone of the ESP8266 based Wemos D1 Mini Pro, A prototype was built and tested, and has been operating flawlessly for almost a month.
I then decided to trim some code and replace a millis() timer routine with a Timer Interrupt routine
(by Khoi Hoang https://github.com/khoih-prog/ESP8266TimerInterrupt).
Running the updated code with the millis() timer routine, all works as expected (no compile warnings or error either), and WebThings Gateway connects.
I then run the identical code with the interrupt based timers, (no compile warnings or errors), and the module will NOT connect to the Gateway it simply disconnects.
Running diagnostics through the serial connection for both code builds does not present any differences, nor does not show anything wrong. WiFi is active, sensors take readings at the intervals programmed.
I am currently re-factoring the code to simplify the sensors structures and adding extra debug functions to help.
Thanks for reading.
Can’t help in any way with code running in the main WT thread as I’m a novice coder, but ADDONS run as a separate process. Writing a smaller addon and passing data to WT might be a (debug) option and eliminate issues.
When I wrote my X10 CM11 serial monitor, I wrote standalone shell monitor tailing the CM11’s usb serial port using the “nc” command. The monitor then sent HTTP events (curl) to a WT addon I also wrote. Output from the serial monitor triggers WT events on X10 devices. Also use numerous Virtual Things devices to hold and initiate random state triggers.
With MicroBlocks, we ran into an issue with the RPi Pico (RP2040) where we can’t set up wireless in some cases when other things are connected to shared pins (like the ElecFreaks Wukong board). Coincidentally, I was reading docs on RPi Pico today and one issue they note kind of sounds similar to your issue where interrupts and Wi-Fi don’t play nice with each other (this is RP2040W which has the Infineon CYW43439 connected to it): “Due to pin limitations, some of the wireless interface pins are shared. The CLK is shared with VSYS monitor, so only when there isn’t an SPI transaction in progress can VSYS be read via the ADC. The Infineon CYW43439 DIN/DOUT and IRQ all share one pin on the RP2040. Only when an SPI transaction isn’t in progress is it suitable to check for IRQs. The interface typically runs at 33MHz.”
Can you create a version of your code without interrupt-based timers?
By the way, there are several MicroBlocks examples (File => Open => Web of Things) that show how to use the Web of Things library to connect boards to a WebThings or Candle gateway. I wrote a short wiki post long ago but might be useful as well. I found debugging Arduino examples too frustrating. MicroBlocks scripting is “live” and therefore much easier to use.
An update of sorts…
Ok, after a lot of code digging and debugging. The culprit has been pounded into submission.
Part of the hardware uses the ESP8266 ADC. Within one library, which was modified by a student team, no documentation, as is normal with undergrads… The readADC() code was being constantly looped, not triggered, as was required, by the timer interrupts.
Thus, whenever the code ran through the loop(){}, the ADC was read all the time.
On thoroughly reading the ESP8266 documentation it makes mention that reading the ADC constantly WILL interfere with the WiFi operation. So, the readADC() code was rewritten to one run once on each timer trigger, by setting a flag in the interrupt service routine. The main loop() was updated to remove all redundant readADC() calls. And the arduino WebThings code tidied up.
Now we have sanity. The students learnt some very important lessons here.
- Revision your code properly
- Add comments where you have made code changes
- Don’t modify libraries without correct procedures
- READ THE DOCUMENTATION
We now have a WebThing that measures and monitors the state of a 5V UPS, controls the power switching and provides all the required information via a WebThings Gateway.
This ESP8266 based module is the frame work for more development work in their engineering projects.
Cheers. everyone.