Wanted to thank you for all the responses and guidance. Cheers, Somu.
That doesnât apply to deep sleep.
Yes, see the Beehive Connected topic.
Is that a button in Blynk?
If so then youâd need to process Blynk.run multiple times and use BLYNK_CONNECTED to know when the value from that button has been received by the board.
Youâd need to stop the device going to sleep, then do the update, then allow sleep again. Thatâs potentially heavy on battery usage, and your timing for waiting until the device is awake and waiting for the update.
That could mean anything, but you donât seem to be saying that dynamic provisioning is now a requirement?
One other issue with battery powered deep sleep devices is that if you use Blynk.begin then if the device canât connect to WiFi or the Blynk server then it will never get to the deep sleep command, as Blynk.begin is a blocking command.
Thatâs why the Beehive Connected sketch used manual WiFi management and Blynk.config/Blynk.begin as this isnât blocking.
Pete.
If by dynamic provisioning you are referring to non-hard coded wifi credentials , yes , definitely thatâs what I would like to try.
By etc. I mean, things like storing the last few values, say last 1 hr, in eprom so that in case of battery dying out, it stores the last few readings and can start from there when the batteries are recharged.
I will redo the code with the beehive example and see how it turns out. Will keep you posted.
Again, many thanks.
Yes, thatâs what Dynamic Provisioning means.
Whatâs your use-case for requiring this, as it increases the complexity by an order of magnitude, and I donât think you have the coding skills for that.
Donât use EEPROM, use SPIFFS OR LittleFS instead.
Life gets much easier if you work-out what your functional requirements and wishlist are to begin with, and communicate these to people who you ask for assistance. It saves you, and us, lots of wasted time.
Pete.
Ok, PeteâŚredid the code based on the Beehive projectâŚhad to make some major changes and reading wrt the esp32 and esp8266 libraries and commands and had to replace / remove some commands which I believe are not supported in esp8266 (for example: RTC_DATA_ATTR int bootCount = 0).
Can you check now if this looks okay now?
I still would want to:
- use dynamic provisioning
- Hopefully this should work if I want to read the weight say once every 6 or12 hrs only
- send SMS once only if the weight exceeds 2kg. Currently it will be sending it every time it wakes up from deep sleep and finds the weight to be more than 2kg
- store some of the data like the last 1 hour readings in some memory on the board as back up for battery dying.
Hereâs the code:
// Template ID, Device Name and Auth Token are provided by the Blynk.Cloud
// See the Device Info tab, or Template settings
#define BLYNK_TEMPLATE_ID "Hidden"
#define BLYNK_DEVICE_NAME "Hidden "
#define BLYNK_AUTH_TOKEN "Hidden"
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include "HX711.h"
// Comment this out to disable prints and save space
#define BLYNK_PRINT Serial
const char auth[] = BLYNK_AUTH_TOKEN;
const char blynk_server [] = "blynk.cloud"; // new variable to hold the name of the Blynk server
const int blynk_port = 8080; // new variable to hold the port used by the Blynk server
// Your WiFi credentials.
// Set password to "" for open networks.
char ssid[] = "Hidden";
char pass[] = "Hidden";
const char* host = "Hidden";
int wifi_connect_count = 0; // New variable to keep track of how manty times we've tried to connect to the Wi-Fi
int wifi_connect_max_retries = 50; // New variable to specify how many attempts we will have at connecting to the Wi-Fi
//float sleep_time_minutes = 1; // New variable - how long (in minutes) we sleep for. As this is a float variable then it can be 0.5 for a 30 second test
// HX711 circuit wiring
HX711 scale;
const int LOADCELL_DOUT_PIN = 4;
const int LOADCELL_SCK_PIN = 5;
//define the parameters for the IFTTT
#define HOSTIFTTT "Hidden"
#define EVENTO "Hidden"
#define IFTTTKEY "Hidden"
WiFiClient client;
int upperLimit = 2;
float calibration_factor = -104625;
float weight = 0;
void getWeight()
{
Serial.println("Initializing the scale");
scale.begin(LOADCELL_DOUT_PIN, LOADCELL_SCK_PIN);
scale.set_scale(calibration_factor); //Adjust to this calibration factor
Serial.print("Reading: ");
Serial.print("The weight in kg is:\t");
weight = ((scale.get_units(10))-0.42); // Assign Weight to reading
Serial.println(weight);
Serial.print("calibration_factor: ");
Serial.print(calibration_factor);
Serial.println();
}
void WiFi_Connect() // New functon to handle the connectuon to the Wi-Fi network
{
Serial.println("Connecting to Wi-Fi");
if (WiFi.status() != WL_CONNECTED)
{
WiFi.begin(ssid, pass); // connect to the network
}
while (WiFi.status() != WL_CONNECTED && wifi_connect_count < wifi_connect_max_retries) // Loop until we've connected, or reached the maximum number of attemps allowed
{
delay(500);
wifi_connect_count++;
Serial.print("Wi-Fi connection - attempt number ");
Serial.println(wifi_connect_count);
}
if (WiFi.status() == WL_CONNECTED)
{
Serial.println("Wi-Fi CONNECTED");
Serial.println();
}
}
void Deep_Sleep_Now()
{
Serial.println("Going to sleep now");
Serial.flush();
ESP.deepSleep(60* 1000000);
}
void sendSMS() {
Serial.println("Initiating to send SMS");
if(client.connected())
{
client.stop();
}
client.flush();
if (client.connect(host,80))
{
Serial.println("Connected");
// build the HTTP request
String toSend = "GET /trigger/";
toSend += EVENTO;
toSend += "/with/key/";
toSend += IFTTTKEY;
toSend += "?value1=";
toSend += weight;
toSend += " HTTP/1.1\r\n";
toSend += "Host: ";
toSend += HOSTIFTTT;
toSend += "\r\n";
toSend += "Connection: close\r\n\r\n";
client.print(toSend);
delay(1000);
Serial.println("SMS Sent");
delay(1000);
}
client.flush();
client.stop();
}
void setup()
{
Serial.begin(115200);
WiFi_Connect(); // Attempt to connect to Wi-Fi
if (WiFi.status() == WL_CONNECTED) // If we managed to connect to Wi-Fi then try to connect to Blynk, else go to sleep
{
Blynk.config(auth, blynk_server, blynk_port); // Initialise the Blynk connection settings
Blynk.connect(); // Attempt to connect to Blynk
}
else
{
Serial.println ("Wi-Fi connection failed - going to sleep");
Deep_Sleep_Now();
}
if (Blynk.connected()) // If we manages to connect to Blynk then carry-on as normal, else go to sleep
{
Serial.println ("Connected to Blynk");
}
else
{
Serial.println("Blynk connection failed - going to sleep");
Deep_Sleep_Now();
}
delay(2000);
}
void loop()
{
delay(2000);
getWeight();
if(weight > upperLimit)
{
Serial.println("Weight is more than 2 kg, sending SMS....");
sendSMS();
}
else
{
Serial.println("Weight is less than 2 kg, not sending SMS");
delay(1000);
}
Blynk.virtualWrite(V3, weight);
Blynk.run(); // Needed to ensure that the Wake Time value is always uploaded to Blynk before going to sleep
delay(100);
Deep_Sleep_Now();
}
Iâve already given you my thoughts on that.
Another previously unmentioned requirement. The maximum deep sleep time, when using latest versions of the ESP core, is around 3.5 hours.
That will require the use of NVR, and as Iâve said earlier you should use SPIFFS or LittleFS for this.
How are you going to do that, if the device is asleep for more than 1 hour?
Why arent you using the Blynk server for storage rather than the device memory?
As Iâve said before, the first task is to define your functional requirements. Once you have these, then they will dictate the code and code structure that needs to be used. Youâre approaching the problem from the wrong direction.
Pete.
- It would help if you can point to some sketches which allows dynamic provisioning for instances where Edgent is not used.
- 3 hrs sleep is alright, if thatâs the hardware constraint
- For checking if SMS has been sent, it would help if you can point me to some sketches wrt the use of SPIFFS or LittleFS
4.Blynk server for storage is a good idea. Any pointers to its implementation will help. I will store the last say 24 hrs of weight data ( at 3 hours interval) - I am following an agile development, rather than a waterfall. Planning to add features as I go along, rather than have it all built at one go. The sketch that I have is
the basic buildâŚi plan to make it better. The objective is simple, a weightscale that is portable (hence dynamic provisioning), run continuously and send data every 3 hrs, run on batteries, send an SMS alert only once when the weight goes beyond a certain value, store latest historical weight values ( in case battery goes down) . Trust i have made the objective and functionality clear.
Now, is the sketch that I have drawn for the basic build looking ok?
Thanks againâŚ
Edgent is the official dynamic provisioning solution for Blynk IoT
There are other potential solutions, such as WiFiManager, but these were developed for Blynk Legacy and there arenât any off the shelf examples that Iâm aware of which incorporate the inclusion of Template ID and Device Name, and which will connect to the correct Blynk server. Also, if you want to speed-up the WiFi connection process with a static IP address then youâd need to add these details to the WiFiManager configuration.
However, as youâve not shared your use-case for dynamic provisioning then itâs difficult to know if there are any other potential issues preventing the potential use of WiFiManager.
Thatâs somewhat outside the scope of this forum, as itâs not specific to Blynk. Google is your friend with this one.
Once again, Iâm struggling with the use-case for this. Youtr stated requirement was:
Youâve not addressed how the 1 hour readings will be taken, given that your device will be asleep for 3.5 hours or more at one time, and once the data has been uploaded to Blynk then it will be on the Blynk server and you donât need to worry about your device dying.
If you were approaching it from a different perspective - wanting to store local data in case of the inability to upload data to Blynk because a connection want possible, then this is a totally different proposition.
The first step of an Agile development lifecycle is the Concept phase, where you define the project goals. Itâs not Agile if you just randomly skip to the Inception phase without understanding the end goal.
You should ask your ScrumMaster for a bit of re-training 
Not really, as youâve previously had OTA updates as an option, and now seem to have dropped this. If itâs a requirement then we need to know if this will be from a device connected to teh same WiFi network as the device, or from a remoite location, as the solutions differ enormously. Youâve also mentioned a TARE reset, but itâs not clear if this is via the app or a physical button, ort if itâs even a requirement now.
As with everything, âthe devil is in the detailâ and weâre almost 30 posts into this conversation (most of which were wasted because you didnât state your basic requirements) and you still havenât assembled a proper high level list of functionality so that we can start to flesh-out the detail behind them and develop a plan that could address as many of these requirements as possible.
The hardware approach that youâre taking may not even be the most appropriate. It may be better, or even necessary, to go for a weigh-station plus base unit solution using LoRa or a SIM based hardware solution. Itâs impossible to say without information.
You are wasting your time (and mine) by attempting to code a solution at this stage. You need to define each requirement in detail before you start the process.
Pete.