Cumulus Support

I installed the latest release yesterday, my first update since b3235. Since that previous release I have been successfully using PHP uploads only.

All looks good in 3257 except for realtime uploads. The dashboard is OK, and I do like the new Select-a-Period chart. My webpages (accessed via index.html, and the standard webpages (via index.htm) are all otherwise fine, and updates to WOW are working.

My only problem is with the gauges, which are not updating because realtimegauges.txt is not being uploaded. My realtime interval is 60s and I only upload this one file. Normal uploads are working fine (interval 5 minutes), and I do not use the standard file method with this but just 3 'Extra' webfiles, including my slightly augmented version of websitedata.json.

I understand from the release notes there are a few changes to PHP Upload. Is there anything I should look for specifically that could affect realtime uploading? Logfile attached after stopping/starting and then running for around 10 mins, and also my Cumulus.ini file (settings unchanged since previous version). The logfile shows the realtime upload attempt. Could it be they are now going to a different directory?

If you are using php upload you have to upload the latest source of it (amended with your secret key) in order for it to work with this release.

Thanks David

I probably should have said, the whole Cumulus MX release is installed on my local system (R-Pi), and I replaced the upload.php file on the remote webhost with the latest one. I made the assumption I could keep the "Secret" the same as before and just copied that into the new php file.

I know PHP uploads are working as Normal interval files are transmitted perfectly, that's the graph json files plus my 2 Extra webfiles (my customised weatherdata.json and a jpg image).

Further apologies. One of my "Extra web files," the .jpg, DOES in fact upload at the realtime interval. It is only realtimegauges.txt that is nowhere to be seen.

From your ini-file

RealtimeTxtCreate=0
RealtimeGaugesTxtCreate=0

I have

RealtimeTxtCreate=1
RealtimeGaugesTxtCreate=1

Internet Settings => Real time Interval Settings
PS
I use SFTP

See above ^^^^^^. Sometimes the upload settings for these two files get unset i.e. they should both be set to 1.

I don’t think the issue is what @rogerthn noticed, since for quite a while it has been possible to not create local standard files and still upload them to server. On the other hand, nothing to lose by testing to enable it, and if it does not resolve the issue, disable it again for reduced sd card wear.

It could be that your web server does not like the new upload of small files via HTTP GET. One other user has had this, the next release will have the option to disable this new feature and revert to using POST for all data. Until I can release this it may be best to revert to v3.26.0

You can keep the new upload.php - it is backwards compatible

RealtimeTxtCreate=1 RealtimeGaugesTxtCreate=1

I had the same problem with the realtime gauges not updating on 3057, changed the ini file as suggested but still no change so reverted until this is fixed in next release.
Also had the server error message with the updated php upload file as well so reverted on that now.

Roger, Dave

I am not using realtime.txt, only realtimegauges.txt. I believe the Create flags you have highlighted control whether a local copy of the relevant file is created or not. Since Mark introduced PHP uploads at build 3231, it has no longer been necessary to create local copies in order to get Cumulus MX to send uploads. I may be wrong about the flags but this is how I understand them. Certainly the .ini file does accurately reflect my settings via the admin interface, and these settings have worked for me up to build 3235, which I was recently using.

Thanks for your help anyway.

Thanks Mark

I think you may be right. Since 12.30 today when I copied the logfile, I notice now that graph json files have stopped uploading. Also it is strange in the log that the uploads appear to be happening fine, but nothing seems to arrive, which does rather point to a host problem. The easiest thing for me now is to revert back to b3235, which is still on my pi. I can then either think about going to b3248 (3.26.0) in due course as you suggest, or waiting for the next one. That's good news regarding upload.php though. In the meantime I will ask my hosting provider about HTTP GET.

By the way if anyone is interested, my hosting is with Krystal.

Thanks for your info (New Forest) Roger. Who do you host with?

Sorry. I only just got a chance to look at the log file you posted in the initial message.

That shows the problem to be your copy of upload.php on your server has not been updated. I know you said you had updated it, but the response you are getting shows otherwise.

Seriously weird! I have the new version with key in my local image and certain I had uploaded it when I uploaded the other few changed script files etc. I even thought I checked the date in the code on the host later. Either I overwrote it again, or just dreamt the whole thing. Always the danger of finishing off an update late at night!

Ok, much appreciated Mark, and sorry to waste people's time. I have just reverted back now, so I'll have another go maybe, over the next few days. If it works OK I'll let you know.

By the way if anyone is interested, my hosting is with Krystal.

Thanks for your info (New Forest) Roger. Who do you host with?

Hi Colin, yes my host is also Krystal. They recently introduced newer faster servers.