meteohub.de

Hi,


I stumbled over something while uploading files with the "template:filename" mechanism and thought I'd mention it, in case it's
useful to you. No urgency — I found a way around it.

Setup: Meteobridge 6.4 on a Raspberry Pi 4 Model B Rev 1.1 (originally build 4267, now on 4297 via auto-update). A nightly
script on the device writes some JSON text files, and scheduled events
upload them via SFTP as templates.

What I see: Smaller files (up to ~200 KB) arrive on the server just fine. But one file grew over time to about 290 KB, and that one arrives
incomplete: the end is missing, and near the point where it gets cut off there is a strange bit of text in the middle of the data that reads

cond_template_buf <

. This happens every night in the same way; as soon as I keep the file smaller, everything is fine again.

So it seems there is a maximum size for template files somewhere around 270 KB? I couldn't find anything about it in the wiki — maybe I just
missed it.

My workaround: I now split the export into two smaller files and upload them with two events — works perfectly, so I'm all set. And I
could imagine the limit is simply there so that the smaller platforms can keep up, which would make perfect sense.

Just wanted to let you know, since the cut-off file looks a bit confusing at first. Happy to send you a sample file if that helps.

Update Aug 23: One more observation that may be related. My box updated itself to 6.4 build 4287 (Aug 21 2026), and last night the data
logger crashed repeatedly — but only during the two minutes when my two larger template uploads (~150 KB and ~185 KB) were being processed. The
uploads themselves arrived complete and valid, and outside those windows everything runs fine. The log shows for each crash:

child process received termination signal (11) in functions:
termination_handler < get_wssensor_temp10 < get_wssensor < get_set <
get_set_long < get_set < get_set_long < ... (repeats)

and once a variant ending in
 

... send_wnet_nosensor < test_inetupload

. After each crash the logger restarts by itself (with the usual

bind (port 22222) 

message) and recovers; the nightly backup afterwards completed normally. On build 4267 the same events ran for days without
any crash, so this might be new in 4287.

Second night (Aug 24): it reproduces exactly, and got worse — by now the box had auto-updated itself again to build 4297 (Aug 23 2026),
and on that build I got 15 crashes in three bursts, each starting precisely at one of the three upload slots (00:30, 00:45, 01:00;
template sizes ~160/150/185 KB). So builds 4287 and 4297 both show it, while 4267 ran the same events for days without any crash. More
trace variants appeared, all pointing into template/sensor processing: 

skipn < print_wind_sensor* < get_set < get_set_long < ...

and

setup_pipe < get_sensorid < print_num_sensor < sensor_copy < get_wssensor < ...

. 

The uploads still arrive complete and valid every
time, but each crash/restart cycle now costs about a minute of per-minute logging (the affected day recorded ~1390 instead of ~1420
minute rows). Happy to provide full log excerpts or remote access if
that helps.

Thanks for the support

BR,
Marco

Correction:
Not a build regression — my mistake in the analysis. The crashes are triggered by my own uploads: large JSON files (150–185 KB) full of nested square brackets, which the template engine apparently tries to parse as variables. Same crashes on 4267, 4287, 4297 and 6.3 once those files existed; I simply had no logs from the earlier nights.

Uploading the identical files raw via SFTP (via Test button) from a script event: zero crashes.

I'll verify tonight whether the automated script run completes cleanly — I expect it will.
Sorry for the confusion.
marco