Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.28.5 (build 3282) - 23 February 2024

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

New PHP Upload Process

From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).

Moderator: mcrossley

water01
Posts: 3163
Joined: Sat 13 Aug 2011 9:33 am
Weather Station: Ecowitt HP2551
Operating System: Windows 10 64bit
Location: Burnham-on-Sea
Contact:

Re: New PHP Upload Process

Post by water01 »

Ctrl+F5 to refresh the cache?
David
Image
Vegit8
Posts: 127
Joined: Fri 27 Sep 2013 2:11 pm
Weather Station: Davis Vantage Pro2
Operating System: Win 10
Location: Dorset
Contact:

Re: New PHP Upload Process

Post by Vegit8 »

Ctrl+F5 to refresh the cache?
Nope - that makes no difference.
As far as I was aware the page is reading data from the remote end, there is no caching locally.

If you hover over the LED the tooltip says "weather station is offline", which it clearly is not, as the page recovers after a couple of cycles...
User avatar
HansR
Posts: 5723
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: New PHP Upload Process

Post by HansR »

I looked with the debugger and found that initially it finds realtimegauges.txt with the correct timestamp. The second and subsequent reads find a realtimegauges.txt with timestamp of 13:21 (always the same) which definitely sets the LED to RED.
The URL is in both cases the same and points to http://geoffwebber.co.uk/weather/realtimegauges.txt.

So the question is: where and how does it load a realtimegauges.txt with a time of 13:21.
It seems to be somewhere on your server and is not overwritten. Is there a version with no delete rights?

Can you locate that file and see what its rights are? It may shed some light on this.

[EDIT:} and the upload of realtimegauges.txt goes without fault, you can find the new versions always on the URL http://geoffwebber.co.uk/weather/realtimegauges.txt. Look at the timestamp to check. So it loads another file!
Hans

https://meteo-wagenborgen.nl
CMX build 3278 ● Ecowitt GW1100/WS80/WH40 ● RPi 3B+ ● Raspberry OS 6.1.21 ● Mono 6.12.0.200
https://meteo-wagenborgen.nl/CMX4/NET8/ (beta)
CMX build 4003+ ● RPi 4B ● RPi OS 6.1.0-rpi7-rpi-v8 aarch64 ● dotnet 8.0.1
freddie
Posts: 2394
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: New PHP Upload Process

Post by freddie »

There's some JavaScript that loads the latest realtimegauges.txt data. When it requests the data it appends the epoch number to the request - this is a cache-busting measure, and the epoch number should be set to the current time. So if you do requests using the same epoch number you end up with the previously requested data (from cache), as the number should change each time the data is requested. So you're not really requesting the data for a specific time, just the latest data.

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.
Freddie
Image
broadstairs
Posts: 694
Joined: Thu 14 Aug 2008 7:17 am
Weather Station: Ecowitt GW1003/GW1103/GW2000
Operating System: Windows 7 and Linux
Location: Broadstairs, Kent, UK
Contact:

Re: New PHP Upload Process

Post by broadstairs »

freddie wrote: Wed 05 Jul 2023 2:08 pm There's some JavaScript that loads the latest realtimegauges.txt data. When it requests the data it appends the epoch number to the request - this is a cache-busting measure, and the epoch number should be set to the current time. So if you do requests using the same epoch number you end up with the previously requested data (from cache), as the number should change each time the data is requested. So you're not really requesting the data for a specific time, just the latest data.

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.
Which means if you have JavaScript disabled this is likely to cause a problem!

Stuart
freddie
Posts: 2394
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: New PHP Upload Process

Post by freddie »

broadstairs wrote: Wed 05 Jul 2023 2:57 pmWhich means if you have JavaScript disabled this is likely to cause a problem!

Stuart
The Cumulus default site uses JavaScript in many places. I can't see it functioning at all without JavaScript. But that's in line with all modern websites.

Hopefully users who disable JavaScript are very much in the minority these days.
Freddie
Image
Vegit8
Posts: 127
Joined: Fri 27 Sep 2013 2:11 pm
Weather Station: Davis Vantage Pro2
Operating System: Win 10
Location: Dorset
Contact:

Re: New PHP Upload Process

Post by Vegit8 »

I am at a loss to explain why you see this behaviour, unfortunately. It will be browser-specific, though, as JavaScript is executed in your browser, not on the server.
Following on from the browser comment, I swapped from Chrome (via Duck Duck GO add in) to Firefox.
I get the same result.

If I had Java script disabled (which I do not) then the gauges would never update (at least that is my understanding).

Now... I did not get this using my standard Chrome/Duck Duck GO set up before upgrading to the latest build of MX and changing to php uploads.
My previous build was 3154

I have not changed any of the web pages from one build to the other.
User avatar
mcrossley
Posts: 12492
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: New PHP Upload Process

Post by mcrossley »

Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?
Vegit8
Posts: 127
Joined: Fri 27 Sep 2013 2:11 pm
Weather Station: Davis Vantage Pro2
Operating System: Win 10
Location: Dorset
Contact:

Re: New PHP Upload Process

Post by Vegit8 »

Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?
Second copy running = No - I have the potential for this disabled in any case via settings.

Now... And this may be due to my not fully understanding the differences between the FTP upload and the php processes.

In C:\CumulusMX\web I have an instance of realtimeguages.txt the date time of this file is 22/06 13:21 (this would be the time/date that is referred to in the status field when the LED is showing RED)
In C:\CumulusMX I have realtime.txt with the same date\time stamp

Settings in http://192.168.1.79:8998/extrawebfiles.html are like this...
extrawebfiles.png
Should I NOT be uploading the realtimeguages.txt file?
Why does the localised version of the 2 realtime .txt files not get updated to the current date / time?

Everything else in the php upload mechanism seems to work OK, I get the feeling that I have missed a step somewhere or have a misconfiguration.

Attached is my latest MXDiags
You do not have the required permissions to view the files attached to this post.
User avatar
HansR
Posts: 5723
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: New PHP Upload Process

Post by HansR »

Vegit8 wrote: Thu 06 Jul 2023 7:40 am
Just continually reading the realtimegauges.txt file I see the UTC time in it incrementing every few seconds, then it goes back to that old stale version for an update.

Do you have an old/second copy of Cumulus running in the background somewhere that is uploading the sale file?
Second copy running = No - I have the potential for this disabled in any case via settings.

Now... And this may be due to my not fully understanding the differences between the FTP upload and the php processes.

In C:\CumulusMX\web I have an instance of realtimeguages.txt the date time of this file is 22/06 13:21 (this would be the time/date that is referred to in the status field when the LED is showing RED)
In C:\CumulusMX I have realtime.txt with the same date\time stamp

Settings in http://192.168.1.79:8998/extrawebfiles.html are like this...

extrawebfiles.png
Should I NOT be uploading the realtimeguages.txt file?
Why does the localised version of the 2 realtime .txt files not get updated to the current date / time?

Everything else in the php upload mechanism seems to work OK, I get the feeling that I have missed a step somewhere or have a misconfiguration.

Attached is my latest MXDiags
I think you can remove the first two lines (realtimegauges and gauges-ss.htm) and the last line (the moon image) and configure those in the interface:
  • Realtimegauges: Internet Settings=>Interval Configuration=>Real time Interval Settings
  • gauges-ss you already skipped yourself so we don't bother
  • moon image: Internet Settings=>Moon Image
Take care that the paths you define are relative to the location of upload.php so don't use a first slash.

I think that should be it.
Hans

https://meteo-wagenborgen.nl
CMX build 3278 ● Ecowitt GW1100/WS80/WH40 ● RPi 3B+ ● Raspberry OS 6.1.21 ● Mono 6.12.0.200
https://meteo-wagenborgen.nl/CMX4/NET8/ (beta)
CMX build 4003+ ● RPi 4B ● RPi OS 6.1.0-rpi7-rpi-v8 aarch64 ● dotnet 8.0.1
Vegit8
Posts: 127
Joined: Fri 27 Sep 2013 2:11 pm
Weather Station: Davis Vantage Pro2
Operating System: Win 10
Location: Dorset
Contact:

Re: New PHP Upload Process

Post by Vegit8 »

I think that should be it.
Hans - Thank you
I have also deleted the errant realtime files - and all seems to be OK still.

I'll keep an eye on it!

Cheers
griffo42
Posts: 220
Joined: Thu 10 Dec 2015 6:41 am
Weather Station: Davis Vantage Pro2
Operating System: Win 11 Home
Location: Brisbane, Queensland, Australia
Contact:

Re: New PHP Upload Process

Post by griffo42 »

I swapped over to PHP uploads yesterday, Sunday 12th November.

Since that time, extra webfiles uploads have not worked with my Saratoga based website.

Attached are 2 zip files from my MX Diags folder - one at the time of changeover and the other being the latest.

Can anyone please point me to the fix?
You do not have the required permissions to view the files attached to this post.
Keith
Davis Vantage Pro2 Model #6152AU - CumulusMX - Win11 - Saratoga/CUMX Default Scripts
https://www.kstwx.net/index.php
https://www.kstwx.net/cumx/index.html
Image
griffo42
Posts: 220
Joined: Thu 10 Dec 2015 6:41 am
Weather Station: Davis Vantage Pro2
Operating System: Win 11 Home
Location: Brisbane, Queensland, Australia
Contact:

Re: New PHP Upload Process

Post by griffo42 »

Further to mine next above and to assist in problem solving, this is a screenshot of my Extra web files settings page.
Screenshot 2023-11-13 104911.png
You do not have the required permissions to view the files attached to this post.
Keith
Davis Vantage Pro2 Model #6152AU - CumulusMX - Win11 - Saratoga/CUMX Default Scripts
https://www.kstwx.net/index.php
https://www.kstwx.net/cumx/index.html
Image
User avatar
PaulMy
Posts: 3731
Joined: Sun 28 Sep 2008 11:54 pm
Weather Station: Davis VP2+ Cumulus1 / CummulusMX
Operating System: Windows8 / Windows10
Location: Komoka, ON Canada
Contact:

Re: New PHP Upload Process

Post by PaulMy »

Hi,
I swapped over to PHP uploads yesterday, Sunday 12th November.
Since that time, extra webfiles uploads have not worked with my Saratoga based website.
I can't follow all the errors and most seem to be extra web files related.

Code: Select all

2023-11-12 15:14:56.813 Realtime[80]: Uploading extra web file d:\CumulusMX\web\realtimegauges.txt to public_html/mxtestv2/realtimegauges.txt
2023-11-12 15:14:56.813 PHP[80]: Uploading to public_html/mxtestv2/realtimegauges.txt
2023-11-12 15:14:56.813 PHP[80]: Sending via GET
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/realtimetags.php: Response code = 500: InternalServerError
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/realtimetags.php: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/realtimetags.php with this user kstwx197

2023-11-12 15:14:56.828 Realtime[80]: Uploading extra web file d:\CumulusMX\web\cldbaseCUtagsT.php to public_html/mxtestv2/CUtags.php
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/websitedata.json: Response code = 500: InternalServerError
2023-11-12 15:14:56.828 PHP[80]: Upload to public_html/mxtestv2/websitedata.json: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/websitedata.json with this user kstwx197

2023-11-12 15:14:56.828 Realtime[80]: Uploading extra web file d:\CumulusMX\web\cldbaseCUtagsT.php to public_html/mxtestv2/cldbaseCUtags.php
2023-11-12 15:14:56.828 PHP[80]: Uploading to public_html/mxtestv2/CUtags.php
2023-11-12 15:14:56.828 PHP[80]: Sending via GET
2023-11-12 15:14:56.828 PHP[80]: Uploading to public_html/mxtestv2/cldbaseCUtags.php
2023-11-12 15:14:56.844 PHP[80]: Sending via GET
2023-11-12 15:14:56.844 PHP[80]: Upload to public_html/mxtestv2/CUtags.php: Response code = 500: InternalServerError
2023-11-12 15:14:56.844 PHP[80]: Upload to public_html/mxtestv2/CUtags.php: Response text follows:
Error: Cannot create the target file public_html/mxtestv2/CUtags.php with this user kstwx197
Generally, unlike with FTP upload, with PHP upload you do not need the starting public_html in the remote path for extra files as the PHP upload is relative to where the upload.php script is located.

Enjoy,
Paul
Davis Vantage Pro2+
C1 www.komokaweather.com/komokaweather-ca
MX www .komokaweather.com/cumulusmxwll/index.htm
MX www.komokaweather.com/cumulusmx/index.php
MX www.komokaweather.com/cumulusmx/index.html

Image
User avatar
PaulMy
Posts: 3731
Joined: Sun 28 Sep 2008 11:54 pm
Weather Station: Davis VP2+ Cumulus1 / CummulusMX
Operating System: Windows8 / Windows10
Location: Komoka, ON Canada
Contact:

Re: New PHP Upload Process

Post by PaulMy »

Hi again,
Just saw your capture after I posted, and you should remove the public_html/ from your Destination filename. And the same in NOAA settings if you upload those.

Enjoy,
Paul
Davis Vantage Pro2+
C1 www.komokaweather.com/komokaweather-ca
MX www .komokaweather.com/cumulusmxwll/index.htm
MX www.komokaweather.com/cumulusmx/index.php
MX www.komokaweather.com/cumulusmx/index.html

Image
Post Reply