CumulusMX standard and external files - Realtime

[BCJKiwi]

For some time with Cumulus1 have run uploads to 6 locations.
Public (Hosted by an external provider):-
Public Cumulus website
Public Saratoga website
A "Shared" Folder - this is used to reduce the upload volume and contains files used by both Cumulus and Saratoga - e.g. reatime.txt, dayfile.txt and others. Websites are configured to get the required files from the shared folder.

Local LAN (Hosted on a WAMP webserver on the local LAN - not accessible from outside):-
The same file setup is replicated on the WAMP webserver PC on the local network.
As Cumulus sends/FTPs files to a single location, there are 3 .cmd (batch) files, realtime.cmd, tagtime.cmd and daily.cmd. These are set up in the appropriate slots in "Internet / External Programs".
The .cmd files contain entries using FTP commands for the additional Public websites and xcopy commands for the local webserver.

For CumulusMX b3005, this whole structure was replicated using different URLS. At this time only the public and Local cumulusmx URLS are used.
CumulusMX is currently configured to send standard files to the public location and the .cmd files are used to send to the LAN WAMP webserver.
EXCEPT for realtime.cmd all is working including tagtime.cmd and daily.cmd (including FTP of dayfle.txt - which does not seem to be part of the standard files).
Realtime.cmd never seems to fire. If run manually it does what it should.
It currently only has two lines to copy realtime.txt and realtimegauges.txt.

So if anyone else has a cmd file in external programs running at the realtime interval - does it work?

Thanks

[BCJKiwi]

Addenda
VUE Console Clock is manually synced to within 1 sec of PC - may drift - won't know for a while.

Cumulus1 (VP2 COM5) and CumulusMX (VUE COM4) are now both running in the same PC as the WAMP server.

[steve]

I'll fix it in the next build - thanks.

[BCJKiwi]

Can confirm that the realtime.cmd external file now "fires" with b3006.

However discovered another 'quirk'.
During testing had noticed the windows command processor displays the Dos box on screen. This was not too much of an issue with the tagtime.cmd but is turning out to be an issue with the realtime.cmd.
It fires so often (15 secs for my setup) and it takes the focus which means if you are doing anything else on the PC focus is lost.
I have tried all the usual methods such as echo off and >nul etc but regardless the dos box comes up on screen and takes focus even if nothing is displayed in it (because of echo off etc).

Cumulus1 did not behave this way so am not sure if it is something that could be changed or not.

I have looked at the alternative of setting up all the files I need to transfer in the 99 available slots (0 - 98) to avoid using the .cmd external programs. I presume this is how it is intended to be done anyway - the initial tests look promising.

Are/should the NOAA and dayfile.txt files be included in the "Web/FTP settings" "include standard Files"?
If not, would still need to run the daily.cmd as there is no daily interval available in extra web files config screen.
The daily.cmd is not an issue as it is only once a day. So don't see the point of adding that to the CumulusMX configuration page.

[mcrossley]

The cmd window appearing has always been an issue afaik, I worked out how to stop it, but you will have to wait until I get back to my home machine for the details. (Iirc it involves creating a shortcut to the batch file and calling that from Cumulus).

The NOAA files have their own 'FTP after updates' and destination options in Cumulus, if it isn't on the config screen it is in Cumulus.ini

[mcrossley]

OK, got back to my machine...

Yes the NOAA FTP settings are there in MX.

The short-cut thing for suppressing cmd popups - I miss remembered, I had to do that for scheduled tasks that run batch files - I use one every minute to populate my realtime MySQL table - when I was running it under a user account. But I since changed that, and run the task under 'SYSTEM' so that is does not interact with the desktop at all.

[steve]

Cumulus1 did not behave this way so am not sure if it is something that could be changed or not.

There's no option on the call that MX uses to fire the command.

I have looked at the alternative of setting up all the files I need to transfer in the 99 available slots (0 - 98) to avoid using the .cmd external programs. I presume this is how it is intended to be done anyway - the initial tests look promising.

Are/should the NOAA and dayfile.txt files be included in the "Web/FTP settings" "include standard Files"?
If not, would still need to run the daily.cmd as there is no daily interval available in extra web files config screen.
The daily.cmd is not an issue as it is only once a day. So don't see the point of adding that to the CumulusMX configuration page.

This is all exactly the same as in Cumulus 1. The 'extra files' get uploaded at either the realtime or 'normal' interval, as configured. There are separate settings for uploading NOAA files once a day. There is no automatic way to upload dayfile.txt without using the daily command.

[BCJKiwi]

Thanks for the confirmations.

Have worked on this thru the day and now have all the 'realtime' and 'tagtime' uploads and "copies" to the local LAN development webserver running from "extra files". When using extra files and the local and remote are the same i.e. the file is just being copied, or does CumulusMX still process it for tags? When using extra files and the local and remote names are the same i.e. the file is just being copied, does CumulusMX still process the local file for tags?
If it processes the file for tags that would seem unnecessary additional work. Perhaps (some time in the distant future when the dust settles - like never!) a further column of tick boxes could be added for a straight copy rather than a tag processing operation.

Have modified the daily.cmd to just upload the dayfile to the public webserver, and, the dayfile and NOAA files to the LAN development webserver. The NOAA option was already set. Too many things to work on that have not been touched in years - memory is not what it used to be!

Just doing some customising of the standard website so I can test the add-on scripts I have published - they are looking good right now but a bit more checking to do.

Thanks a gain for all your great work on this Steve

[duke]

When using extra files and the local and remote are the same i.e. the file is just being copied, or does CumulusMX still process it for tags?

I may misunderstand but there is a separate 'process' column with check boxes for just this.

[BCJKiwi]

The "process" column (if my understanding is correct) sends the file through some form of parser so it can replace any <#tag>'s with the value for that tag.

I see my wording;

When using extra files and the local and remote are the same i.e. the file is just being copied, or does CumulusMX still process it for tags?

was not clear in the previous post - did not proof my edits! It should have read;

When using extra files and the local and remote names are the same i.e. the file is just being copied, does CumulusMX still process the local file for tags?

Have edited the previous post.

If an existing complete file that does not require any tag processing is just to be copied, then it does not need to go through the parsing process.

As discussed above, I "Copy" already processed files to a second webserver so these don't need to 'processed' for tags as there are no tags in the file as they have been processed already.

[steve]

It's quite simple. Cumulus processes the file to replace web tags if you tell it to. You do that by ticking the 'process' box.

I don't understand why you would want to have the local and remote file names the same - what does that achieve? If you mean the same terminal file name but in a different directory, you still have to tell it explicitly whether you want it to process the web tags or not, as otherwise how would it know?

If an existing complete file that does not require any tag processing is just to be copied, then it does not need to go through the parsing process.

As discussed above, I "Copy" already processed files to a second webserver so these don't need to 'processed' for tags as there are no tags in the file as they have been processed already.

So in that situation, the files don't need to be processed, so you don't tick the process box.

[BCJKiwi]

So in that situation, the files don't need to be processed, so you don't tick the process box.

Duh! too simple! Had always assumed that if there were no ticks anywhere then nothing would happen.