Hi,
I am using the api/batch/update API to upload timestamped data. After some (not many) API calls I ran into a strange issue: The most recent value is displayed in the gauge, however, none of the values are shown in the chart. This smells like an access limitation, but it is not quite clear what rule applies.
The documentation states:
LIMIT: You can send a max of 10,000 data points per day per device. No matter if you split it into multiple sets or send all data once.
This limit can vary based on the plan you are using.
Also we find this about API limits:
Max number of file uploads (product/organization logos, firmware for shipment, data import) per user per day: 10 Free / 25 Maker / 50 PRO
Anyone knows what applies?
Thanks 
Is the “Enable history data” option enabled for each datastream that you’re updating?
Pete.
Yes, history data is activated. In fact, data sent via Blynk.virtualWrite still ends up in the chart.
So do you have multiple devices writing data to the same Blynk device?
Pete.
No, it’s the same device. But as part of my debugging I tried sending data via Blynk.virtualWrite. However, in the end I will need to send the data in batches to save energy. Therefore it would be good to know the limitations.
Do you mean power, or data traffic?
Pete.
I mean battery power. In my project I use an LTE/WiFi router to send the data. That router is switched on by the ESP32, and it is the main energy consumer. So the plan is to send the data once per day in a batch.
There is an update: Now in the morning after several hours, the data that I sent yesterday appeared in the chart. This happened without interacting with Blynk again, the device was off all the time. I just sent another batch of data, with the same symptoms as yesterday: the most recent data appears in the gauge, but none of the data appears in the chart. So it appears there is a huge delay between sending the data and appearing in the chart.
I will now wait for 24 hours to get out of any potential quota limitations. Will update again.
There’s nothing to stop you doing an update of the datastreams once per day using Blynk.VirtualWrite().
You’d need to ensure that the connection to the Blynk server was established first, so it probably makes sense to put the code in BLYNK_CONNECTED but I doubt that there would be much difference in power consumption.
Pete.
In that hand-shake once per day I want to send measurements which I collected during the past 24 hours. And those should appear in the chart with the right time stamp. My understanding is that this is not possible with Blyk.VirtualWrite().
Well, switching on the router and waiting for LTE connection establishment takes about 30 seconds. Sending the data takes less than 1 second. So if I want to collect data once per hour, then sending the data immediately via Blynk.VirtualWrite() requires the router to be switched on a total of 12 minutes. One batch upload requires only 30 seconds of router time.
It is possible if you use Blynk.beginGroup(ts) although the ts parameter needs to be in UNIX time, but that’s not too difficult if you use the ezTime library.
Pete.
Oh right, that seems to be an option. Feels a bit of a hack to use it for sending past values, but I do not see why it should not work.
Thanks for pointing this out!
Can’t think of any other reason why the timestamp option would be included.
Pete.
This is confirmed to work, many thanks for pointing out Blynk.beginGroup(ts), Peter!
1 Like