Pete, I have updated Post#2 with the up-to date code that is currently running on the D1 Mini.
Currently the board is powered using a 12V suppy and set down to 5Vs.
At the moment I am not at the device but when I get back, I will connect it to my computer and leave the serial monitor open and will attach the output.
As for the settings.h file, the only changes I’ve made is increase the timeout values and reset pins #define WIFI_NET_CONNECT_TIMEOUT 160000 #define WIFI_CLOUD_CONNECT_TIMEOUT 160000
Full Settings.h
#if defined(USE_NODE_MCU_BOARD) || defined(USE_WEMOS_D1_MINI)
#if defined(USE_WEMOS_D1_MINI)
#warning "This board does not have a button. Connect a button to gpio0 <> GND"
#endif
#define BOARD_BUTTON_PIN D8
#define BOARD_BUTTON_ACTIVE_LOW true
#define BOARD_LED_PIN 2
#define BOARD_LED_INVERSE true
#define BOARD_LED_BRIGHTNESS 255
#elif defined(USE_SPARKFUN_BLYNK_BOARD)
#define BOARD_BUTTON_PIN D8
#define BOARD_BUTTON_ACTIVE_LOW true
#define BOARD_LED_PIN_WS2812 D7
#define BOARD_LED_BRIGHTNESS 64
#elif defined(USE_WITTY_CLOUD_BOARD)
#define BOARD_BUTTON_PIN D7
#define BOARD_BUTTON_ACTIVE_LOW true
#define BOARD_LED_PIN_R 15
#define BOARD_LED_PIN_G 12
#define BOARD_LED_PIN_B 13
#define BOARD_LED_INVERSE false
#define BOARD_LED_BRIGHTNESS 64
#else
#warning "Custom board configuration is used"
#define BOARD_BUTTON_PIN D8 // Pin where user button is attached
#define BOARD_BUTTON_ACTIVE_LOW true // true if button is "active-low"
//#define BOARD_LED_PIN D7 // Set LED pin - if you have a single-color LED attached
//#define BOARD_LED_PIN_R 15 // Set R,G,B pins - if your LED is PWM RGB
//#define BOARD_LED_PIN_G 12
//#define BOARD_LED_PIN_B 13
//#define BOARD_LED_PIN_WS2812 4 // Set if your LED is WS2812 RGB
#define BOARD_LED_INVERSE false // true if LED is common anode, false if common cathode
#define BOARD_LED_BRIGHTNESS 64 // 0..255 brightness control
#endif
/*
* Advanced options
*/
#define BUTTON_HOLD_TIME_INDICATION 3000
#define BUTTON_HOLD_TIME_ACTION 10000
#define BUTTON_PRESS_TIME_ACTION 50
#define BOARD_PWM_MAX 1023
#if !defined(CONFIG_DEVICE_PREFIX)
#define CONFIG_DEVICE_PREFIX "Blynk"
#endif
#if !defined(CONFIG_AP_URL)
#define CONFIG_AP_URL "blynk.setup"
#endif
#if !defined(CONFIG_DEFAULT_SERVER)
#define CONFIG_DEFAULT_SERVER "blynk.cloud"
#endif
#if !defined(CONFIG_DEFAULT_PORT)
#define CONFIG_DEFAULT_PORT 443
#endif
#define WIFI_CLOUD_MAX_RETRIES 500
#define WIFI_NET_CONNECT_TIMEOUT 160000
#define WIFI_CLOUD_CONNECT_TIMEOUT 160000
#define WIFI_AP_IP IPAddress(192, 168, 4, 1)
#define WIFI_AP_Subnet IPAddress(255, 255, 255, 0)
//#define WIFI_CAPTIVE_PORTAL_ENABLE
#define USE_TICKER
//#define USE_TIMER_ONE
//#define USE_TIMER_THREE
//#define USE_TIMER_FIVE
//#define USE_PTHREAD
#define BLYNK_NO_DEFAULT_BANNER
#if defined(APP_DEBUG)
#define DEBUG_PRINT(...) BLYNK_LOG1(__VA_ARGS__)
#define DEBUG_PRINTF(...) BLYNK_LOG(__VA_ARGS__)
#else
#define DEBUG_PRINT(...)
#define DEBUG_PRINTF(...)
#endif
What confuses me more is why this same issue occurs even when I upload a blank BlynkEdgent file from the examples folder. Is it safe to assume that the my code isn’t casuing this issue?
So you’re always powering it via USB.
Have you tried a different USB cable?
Is thee a reason why you’ve not kept the defaults and connected a push bottom between GPIO0 (the pin labelled D3) and GND ?
When you used a clean Edgent example did you keep Settings.h in its original state and add this button?
I don’t like to see “D” numbers used in code, especially when you also use GPIO numbers in other places too.
The blocking delays, and the timers that all attempt to run at the same time probably don’t help with your device stability.
TBH, you’d be better putting the untouched Edgent example sketch (untouched except for adding-in the two lines of firmware configuration and un-commenting the correct board type) onto a different Wemos and testing that way.
Do you actually need the Edgent functionality? If so, is it just the Blynk.Ait functionality of dynamic provisioning too?
Thank you for the Guide to use BlynkTimer, I will have a look and firgure out how to incopparate it in my existing code. I’m a bit hesistant though as I have so many delay() functions to replace…
TBH, you’d be better putting the untouched Edgent example sketch (untouched except for adding-in the two lines of firmware configuration and un-commenting the correct board type) onto a different Wemos and testing that way.
I am doing exactly this. I initially thought it was a bad D1 mini with the notorious underpowered voltage regulator (100mA peak current as opposed to the correct 500mA), but I verified that and my boards have the correct VR.
Do you actually need the Edgent functionality? If so, is it just the Blynk.Ait functionality of dynamic provisioning too?
I’m sorry but what do you mean by needing the edgent function?
You’ve chosen to use the Edgent example as the basis for your sketch.
Edgent is an extremely complex example which provides Blynk.Air (OTA updates) and Dynamic Provisioning (WiFi credentials are enter via the app, and the Auth token is allocated dynamically) as opposed to static provisioning where the WiFi credentials are hard-coded in your sketch along with your Auth token.
Why have you chosen the Edgent example as the basis for your sketch, instead of a much simpler static provisioning example?
Interesting!
I assumed for many years now that BlynkEdgent is the libary for Blynk 2.0 and that the other examples were for Blynk Legacy… My bad for the assumption.
I do occasionally use OTA since the D1 mini is housed in a water tight encloser but I don’t mind loosing that function if it means for a more reliable system!
I don’t mind testing it with an alternate libary. Would you recommend the use of example “ESP8266_Standalone” instead? Can I simply paste the main part of my code from Edgent to this?
If you’re careful yes, but avoid all the Edgent related stuff.
Personally, I’d start with the standalone example and get it online before going any further. Basically, if it’s not code that you’ve written then leave it out.
It’s possible to add Blynk.Air functionality into the standalone sketch, but I’d do this last of all, once everything else is working correctly.
Details here…
Understood, This is my code and I just copy pasted the main section, avoiding Edgent code and it complied succesfully. I will flash it when I get back home and give you an update soon.
Thank you
Greetings!
Apologies for the dissapearance, I have been busy trying as suggested and wanted to test and be absolutly sure before giving an update on my situation.
Unfortunately even after convering D pins to GPIO number and reducing the number of delays to the absoulute bare minimum, my device still goes offline. I am still trying to understand millis function which I am practicing to incoperate on another project before doing so on this project, which I can’t risk anymore failure.
I tried moving to “ESP8266_Standalone” but that too goes offline randomly and for many many hours if not days, until I unplug the power. I tried with a blank sketch, just the skeleton code with credential only ,and it still crashes (therefore hopefully concluding that it isn’t the code that is making my device go offline).
I now removed the board from its enclosure and connected it to my computer with the serial monitor open. I will leave it like this till it goes offline again and will upload any crash messages displayed.
Thank you.
You shouldn’t need to use delays at all in the vast majority of situations.
Doing a millis comparison to figure-out if an amount of time has passed isn’t the solution either, in most cases.
millis comparisons only work inside a loop, and the BLYNK_WRITE callbacks don’t loop. You could create a loop, but this would just block code executor be no better than delays, or you could do the millis comparison in the void loop, but that just clutters your void loop, which isn’t what you want either - if you want to avoid disconnections.
Using BlynkTimer is the preferred solution.
So far you’ve been talking about the device going offline, not crashing.
When it crashes what crash dump data do you see in the serial monitor, and have you tried decoding this with the ESP Exception Decoder?
Thats a sensible approach.
Is the device crashing, or simply going offline?
Have you added any code to check when it goes offline, and attempt to re-connect?
This all seems very hypothetical at the moment, because you aren’t providing hard facts and posting the code and full details of the symptoms.
Hello Pete!
Up until today I have not logged the serial monitor as the board was in a sealed box, powered with its own power supply. As mensioned I have removed the board and currently monitoring the serial output.
I am yet to comfirm from the serial monitor output whether board is crashing or the simply going offline. However looking at the blynk app timeline, the device is mojority of the time offline for exactly 7 Hours and 42 Minutes and comes back online. Its even gone offline for 2 Days and 8 Hours.
But as I mensioned in my first post, the board is still connected to my router, I confirmed this by viewing the router admin portal.
Also the time displayed in the serial monitor is not my current time where I am living, could that possibly cause any issues?
Please see attached serial monitor when the device booted a couple of hours ago, and the app timeline.
The reason is because there seemed to be absolutely no improvements when using ““ESP8266_Standalone” and secondly since the device is in an enclosure and I am tinkering with the code, trial and error changes, to try and resolve this issue, Blynk Air is extremly useful.
Well it didnt take long for the device to go offline and the serial monitor output is interesting.
As suspected before the board isnt loosing connection with the router, nor is the board crashing. It simply looses looses connnection with Blynk’s server and continously tries to establish a connection to the sever and looses it again (as seen in the 3rd attached picture).
What can be causing this? I’ve read Blynk servers will disconnect a device if it recieves spam pings, but nothing in my code will cause that?!
Update-
The device is back only after 19 minutes.
Looking at the SM, the board doesnt crash or reboot, it just reconnects to the server after many failed
attempts
As I explained before, it’s very easy to add Blynk.Air to the standalone sketch by pasting the code in the example.
Edgent makes it extremely difficult to make any changes to the connection routines, so it’s a bad starting point for resolving this type of issue.
When you post serial output it’s far better if you copy the text and paste it with triple backticks, the same as when you post code.
The device can’t communicate with the Blynk server anymore. This is probably because daya packets that are intended for the Blynk server aren’t making it through, or your ISP is blocking them.
You could try using port 80 (far easier when you use the non-Edgent) examples) and possibly try turning-on Blynk debugging or Core Debugging (in the IDE).
Understood, I will revert back to non edgent Blynk. I am not too keen about Blynk Air at the moment since the board is connected to my computer and as you mensioned earlier, I should focus fixing this before trying to incopperate Air to the code.
Thank you for the SM suggestion, I will keep that in mind
May I know how to change the port to 80 and turn on Blynk debugging for non-edgent sketches?
