I’d suggest storing that data on the Blynk server and retrieving it with a virtual sync when your device boots.
Pete.
@PeteKnight I have a feeling that the amount of data involved is huge i.e. it needs 60 minutes of data before it can proceed.
@Costas, maybe writing it to virtual pins and visualising in Superchart, and reporting via the reporting widget is a better solution then?
Pete.
I don’t think so.
I have been building a crypto trading bot to run with Blynk and it needs a huge amount of historic data to make sensible decisions. I feel the same data requirement applies to this Blynker’s project.
1 Like
But not everyone needs a Blynk app to keep track of their bitcoin fortune 
Probably because it resembles something I’ve done in the past, the project sounded like a weather station, with a Bluetooth serial data feed from sensors and the desire to hold rolling rainfall values for the past 60 minutes.
I use an array to hold that data, and it obviously needs 60 minutes to populate the array. I also have a rolling 24 hour rainfall array, so in my case it takes a day to re-populate that in case of a reboot.
As it happens, I’m using MQTT to send my values to Node-Red, and disconnection/random reboots isn’t a problem I have, but if it was then writing the values for each minute/hour array to 60/24 virtual Blynk pins and retrieving them on startup would be one option. Obviously a disconnection of more than one minute would screw-up the average over the past hour, but in this case that doesn’t sound like an issue.
Using Superchart to visualise the data is still the easiest way I find to make visual sense of the data though.
Pete.
4 remote radio sensors send each about 60 bytes of data every 20 minutes, staggered, every 5 minutes. Each sensor sends data 3 times per hour. This data is used in moving average calculations. Storing data on the server would mean the calculated mov. avg. is to be sent each time, and then retrieved upon the next reception. This is doable, but the issue then is that my program would fully depend on retrieved data to work. Currently the algorithms work even without internet connection.
I use Blynk now to update values and graphs on smartphone, nothing else.
Over what timeframe do you compute the moving average?
Unless it’s a long duration it doesn’t seem to be too much data.
For me it’s 15kb of data every 5s (ideally every 1.2s) for as long as possible but at least 15 minutes (min 2.7mb). Potentially we would use the 15MB SPIFFS on the WeMos Pro if they ever sort out the memory above 3MB SPIFFS on the device.
The weighting depends on the variable, but worst case it is 20%, so it would take at most 2 to 3 hours to approximate the final value. However, this impacts the actions taken as a result; I might introduce a delay using reboot detection to prevent actions to be taken within a few hours after reboot. But then every reboot interferes with proper program operation. So my route taken so far is to try and prevent reboots at all.
PS: Unable to answer sooner, a 4 message/day limit seems imposed.
Can you plse elaborate on the SPIFFS and its usage for permanent data storage? I use a generic ESP8266 mounted on a self-made prototyping PCB (similar to Wemos concept).
All 4MB ESP’s can have 3MB of SPIFFS, as set in the Arduino IDE.
The WeMos Pro is a 16MB ESP and in theory can have 15MB of SPIFFS. Despite the product being released a couple of years ago there has been very little progress in getting the 15MB SPIFFS to work.
But you can configure the Pro to have 3MB SPIFFS like the 4MB ESP’s and all is fine.
SPIFFS is built into the ESP8266 core firmware but the GitHub is https://github.com/pellepl/spiffs
Even the tacky 1MB ESP’s can have 512kb of SPIFFS.