@indra_b3j0 please edit your post, using the pencil icon at the bottom, and add triple backticks at the beginning and end of your code so that it displays correctly.
Triple backticks look like this:
```
Connecting via a WiFi hotspot on a phone is somewhat difficult, as some mobile providers block some ports and protocols, which can stop Blynk devices talking to the Blynk server.
You could try changing your Blynk.begin command to this:
This will force the use of port 8080 rather than 80, which may be blocked by your mobile ISP.
You may also wish to use a much simpler sketch. Your sketch has multiple problems with timing. The DHT11 has a maximum sampling rate of 1 reading per second (which to be honest is optimistic and I’d go for every 5 seconds) and you are trying to read it twice every half second.
You also have 4 timers attempting to call different functions at precisely the same time, which isn’t good practice.
Actually, i want to set the pump to be active (ON) and OFF when the soil moisture reach certain values,but it cant since its still ON-OFF regularly with interval, How do i fix this please?Thanks before
As I said earlier, your code has too many timing issues, and I’ve just spotted that you have a delay in there, which makes things even more unfriendly from a Blynk point of view.
You also seem to have a liking for putting actions into separate functions, rather than simply executing all the commands you require in one function. This makes your code difficult to debug, and serves no purpose unless your functions are blocks of code that will be called from multiple places within your code.
By far the best way of coding is with a pencil and paper - mapping out the program flow and designing the functionality, then writing the blocks of code to perform these functions.
It’s also extremely helpful (to you for debugging and future enhancements and to others for basic understanding) if you use lots of in-code documentation.
Code is much easier to follow if you have your library #include commands first, followed by your variable declarations/initialisations and in-code documentation explaining what each variable does, and why.
BLYNK_WRITE callback functions should have explanations about the type of widget that is being used, what it’s function is in the app, and what actions should be taken when the widget value changes.
If you do this with your code you’ll begin to understand why it currently does what it does, and how to change that behaviour so that it does what you want it to.