You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[167](https://github.com/tobiasschuerg/InfluxDB-Client-for-Arduino/pull/167) - Added possibility to disable retrying by setting `maxRetryAttempts` to zero: `client.setWriteOptions(WriteOptions().maxRetryAttempts(0));`
6
+
-[172](https://github.com/tobiasschuerg/InfluxDB-Client-for-Arduino/pull/170) - Added directly streaming batch for write. It can be enable by `InfluxDBClient::setStreamWrite(bool enable = true)`. Writing by streaming lines of batch saves RAM as it sends data without allocating a buffer. On the other hand, this way of writing is about half times slower than the classic way, when allocating the buffer for writing the whole batch.
When a write precision is configured, the client will automatically assign the current time to the timestamp of each written point which doesn't have a timestamp assigned.
177
179
178
180
If you want to manage timestamp on your own, there are several ways to set the timestamp explicitly.
179
-
-`setTime(WritePrecision writePrecision)` - Sets the timestamp to the actual time in the desired precision
181
+
-`setTime(WritePrecision writePrecision)` - Sets the timestamp to the actual time in the desired precision. The same precision must set in WriteOptions.
180
182
-`setTime(unsigned long long timestamp)` - Sets the timestamp to an offset since the epoch. Correct precision must be set InfluxDBClient::setWriteOptions.
181
183
-`setTime(String timestamp)` - Sets the timestamp to an offset since the epoch. Correct precision must be set InfluxDBClient::setWriteOptions.
Setting batch size depends on data gathering and DB updating strategy.
230
232
231
233
If data is written in short periods (seconds), the batch size should be set according to your expected write periods and update frequency requirements.
232
-
For example, if you would like to see updates (on the dashboard or in processing) each minute and you are measuring a single value (1 point) every 10s (6 points per minute), the batch size should be 6. If it is sufficient to update each hour and you are creating 1 point each minute, your batch size should be 60. The maximum recommended batch size is 200. Maximum batch size depends on the RAM of the device (80KB for ESP8266 and 512KB for ESP32).
234
+
For example, if you would like to see updates (on the dashboard or in processing) each minute and you are measuring a single value (1 point) every 10s (6 points per minute), the batch size should be 6. If it is sufficient to update each hour and you are creating 1 point each minute, your batch size should be 60.
233
235
234
236
In cases where the data should be written in longer periods and gathered data consists of several points, the batch size should be set to the expected number of points to be gathered.
235
237
236
238
To set the batch size we use `WriteOptions` object and [setWriteOptions](#write-options) function:
In case cases where the number of points is not always the same, set the batch size to the maximum number of points and use the `flushBuffer()` function to force writing to the database. See [Buffer Handling](#buffer-handling-and-retrying) for more details.
259
261
262
+
### Large batch size
263
+
The maximum batch size depends on the available RAM of the device (~45KB for ESP8266 and ~260KB for ESP32). Larger batch size, >100 for ESP8255, >2000 for ESP32, must be chosen carefully to not crash the app with out of memory error. The Stream write mode must be used, see [Write Modes](#write-modes)
264
+
265
+
Always determine your typical line length using `client.pointToLineProtocol(point).length()`. For example, ESP32 can handle 2048 lines with an average length of 69. When the length of line or batch size is increased, the device becomes unstable, even there is more than 76k, it cannot send data or even crashes. ESP8266 handles successfully 330 of such lines.
266
+
267
+
:warning: Thoroughly test your app when using large batch files.
268
+
269
+
### Write Modes
270
+
Client has two modes of writing:
271
+
- Buffer (default)
272
+
- Stream
273
+
274
+
Writing is performed the way that client keeps written lines (points) separately and when a batch is completed, it allocates a data buffer for sending to a server via WiFi Client.
275
+
This is the fastest way to write data but requires some amount of free memory. Thus a big batch size cannot be used.
276
+
277
+
Another way of writing is *stream write*.
278
+
```cpp
279
+
// Enables stream write
280
+
client.setStreamWrite(true);
281
+
```
282
+
In this mode client continuously streams lines from batch to WiFi Client. No buffer allocation. As lines are allocated separately, it avoids problems with max allocable block size. The downside is, that writing is about 50% slower than in the Buffer mode.
283
+
260
284
## Buffer Handling and Retrying
261
285
InfluxDB contains an underlying buffer for handling writing in batches and automatic retrying on server back-pressure and connection failure.
262
286
@@ -300,12 +324,15 @@ Writing points can be controlled via `WriteOptions`, which is set in the `setWri
300
324
| batchSize | `1` | Number of points that will be written to the database at once |
301
325
| bufferSize | `5` | Maximum number of points in buffer. Buffer contains new data that will be written to the database and also data that failed to be written due to network failure or server overloading |
302
326
| flushInterval | `60` | Maximum time(in seconds) data will be held in buffer before points are written to the db |
327
+
| retryInterval | `5` | Default retry interval in sec, if not sent by server. Value `0` disables retrying |
328
+
| maxRetryInterval | `300` | Maximum retry interval in sec |
329
+
| maxRetryAttempts | `3` | Maximum count of retry attempts of failed writes |
303
330
304
331
## HTTP Options
305
332
`HTTPOptions` controls some aspects of HTTP communication and they are set via `setHTTPOptions` function:
306
333
| Parameter | Default Value | Meaning |
307
334
|-----------|---------------|---------|
308
-
| reuseConnection | `false` | Whether HTTP connection should be kept open after initial communication. Usable for frequent writes/queries. |
335
+
| connectionReuse | `false` | Whether HTTP connection should be kept open after initial communication. Usable for frequent writes/queries. |
309
336
| httpReadTimeout | `5000` | Timeout (ms) for reading server response |
0 commit comments