Wim, if the user has entered a WeatherFlow station ID, could add in the ‘Extra links’ in the menu, in addition to the link to the WeatherFlow map page, a new link to the WeatherFlow weather station data/info page - the link should have this format:
Experimenting with using my own data for my historical charts. The system is working fine.
I am wondering if there is a way to upload my historical data for 2019 and the current Month to the text files on my server??
It appears to me that the Cron jobs will not run unless you select that in the settings menu. It would be nice if you could be collecting your WD data on your sever via the cron jobs, but still be using WU data as long as it it is working. So I could be collecting data every day, and if the WU api/charts quit working again, I can switch to “my” data files, and have charts that contain complete historical data.
So the Cron jobs would be running as scheduled, collecting data, but the charts would come be served from WU api.
It is not exactly clear to me what you want. first my thoughts about this.
1WU promised that they will get the .CSv or a replacement working.
[li]Downloading the yearly data from WU is all we need to make a backup.
As long as we have the yearly file backup somewhere we can write a simple program to change the format to the .txt files the crons create now.[/li]
The daily file is automatically created when WU stops delivering the .CSV’s.
So this new month you should save the yearly file somewhere else, to make sure that it is not written over.
But if I understand you correctly, you want the stationcron to save to the .txt files now ALSO, although you are using WU for the charts.
To do so, change 1 line in w34_cron_stationcron.php, which reads now
if ($charts_from == "WU") {return; }
to
# if ($charts_from == "WU") {return; }
You can manually run stationcron or wait 5 minutes and check the /chartsmydata/today.txt file
You have to run the w34_cron_addtoyear.php also daily at 23:55
That is exactly what I meant.
FYI: WU api has been running fine for almost 30 days now. But it would be nice to be creating a backup set of data at the same time, in case WU goes dark again.
You should us w34_module_test.php and select a file from the dropdown.
The messages tell us that there is not file clientraw.txt.
3.1 WD has to upload that file and
3.2 you have to tell in Easyweahter what the exact location is.
Check your settings, NEVER EVER start a link with /, that means the ROOT of your site at the host, often “public_html”
You should us ‘./clientraw.txt’ if it is in the pws folder
Or '…/clientraw.txt" if it is in the root.
But again, without the URL there is not much anyone can do.
My small alert box (Top Right) shows a forecast in the box. Not sure what is in the box if there is a weather alert, as I have not had one since setting up the July issue. The forecast seems to be the same all the time. “Mostly cloudy throughout the day.”, which is not correct. I see that others show the same thing and others say “no weather alert”. Where does this come from and can it be changed either to “no weather alert” or a forecast that is correct. I see a discussion of this around reply #35, but there was no definitive answer that I saw.
The webcam block is elongating my webcam image, is there a way to change the settings to keep the “aspect ratio” so it does not stretch out the image. I looked around in the webcam block, but had no luck.
STRONG ADVISE / WARNING
You should really try to not use a HTTP- link as that will force to load the file by internet every time it is accessed. Easyweather livedata file location:
Path to your realtime data file. Not used with an API.
Correct path is essential for live realtime data display.
Example “…/clientraw.txt” when your file is in the root.
You should set the path to that file, for our example we use clientraw.txt.
Do not [b][color=red]use an external ink such as http:// a[/color][/b]s that will drastically increase the load on your server.
In this case the errors you mentioned are irrelevant.
A script can not ask for the file-modifed-time of a remote (http://) file and during debug all errors are printed.
The file is retrieved and displayed correctly, albeit with extra overhead.