@Mullemj I’ve removed your code because although you edited your post, you didn’t use the correct triple backtick characters, despite me giving you some to copy/paste, and despite there being an example of how to correctly format code in the text that appeared when you created this topic.
Blynk.begin is a blocking function, and if your device fails to connect to either WiFi or the Blynk server it will never get to the deepsleep command, and there flatten your battery.
As a result, you should manage your own WiFi connection, then use Blynk.config and Blynk.begin when using deepsleep.
Blynk requires the Blynk.run command to be executed in order for the Blynk magic to work.
If you use Blynk.config then Blynk.connect will be performed the first time that a Blynk.run is encountered. You could therefore argue that Blynk.connect is redundant, but I like to use it anyway - it makes the program logic easier to follow.
Blynk.syncVirtual, located inside a BLYNK_CONNECTED function will cause the corresponding BLYNK_WRITE function to trigger once the device wakes up and has established a connection to the Blynk server.
Without this in place, the BLYNK_WRITE function will only trigger if you happen to change the value of the corresponding widget at the exact time that the device wakes up.
As far as program structure is concerned, you have to throw all of the normal Blynk coding rules out of the window. But, it depends on what you want to achieve with your project.
The connection to Blynk takes a while, and if you put a Blynk.syncVirtual immediately after Blynk.connect in your void loop then the sync won’t work - which is why you put it in the BLYNK_CONNECTED function.
If you want to check the state of one widget then branch your program depending on what that widget value is, then you could potentially put virtually all of your code in the BLYNK_WRITE function. Or, you could set a global flag variable within your BLYNK_WRITE and do your code branching within your void loop.
I’d always recommend that you avoid the use of BlynkTimer in deep sleep sketches.
Also, it’s a good idea to use a static IP address, as most routers give a quicker connection this way (provided you set-up a static device in your router) but it depends how critical it is to minimise your wake time.
If wake time is really critical then you’re better using HTTP(S) API calls to Blynk rather than going through the Blynk connect process.
Assuming that you don’t go down the API route, this topic shows a good foundation sketch…
The examples in that topic are for Blynk Legacy, but if you’re using Blynk IoT then it’s fairy easy to modify the sketch.
This is an example of how…
but I’d suggest starting with the Beehive Connected version of the code and making the necessary changes, as you’ll be starting from a better place with that code.
Pete.