high/lows question ** Solved **

Ask a Question
,
1

I’m also having a problem with high/low temps and high/low wind speed, but only for the current day AND only for the current release of PWS Dashboard. Here are some links and details:

Primary implementation:

PWS_Dashboard template setup version PWSD_2004

Upgrade implementation:

PWS_Dashboard template setup (2012_lts)

I’m not sure where to pull the exact release version information from. To be clear: this is NOT an “upgrade” in the classic definition, but a parallel install to try to avoid any configuration issues.

Other than adding API keys, etc. to the Upgrade implementation (pwsWD.next link) I’ve only modified the _my_settings/languages.txt file to uncomment the en-us line. I haven’t configured NWS alerts, changed the first row layout, etc.

On the old/primary implementation the “Max-Min Temperature °F” and the “Max Wind | Gust - mph” blocks are correctly populated. In the new/upgrade implementation the “Max Wind | Gust - mph” and “Max-Min Temperature °F” have current month and current year data, but are missing current day.

I downloaded the current release a few hours ago and uploaded it in to a new directory on my hosting server (pwsWD.next/ vs. pwsWD/). This implementation only uses Ambient Weather API calls, no local clientraw.txt or other files.

The output from PWS_module_test.php for temp_c_small.php is:
Notice: Undefined index: winddir_avg2m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 346

Notice: Undefined index: windspdmph_avg10m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 461

Notice: Undefined index: winddir_avg10m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 477

Warning: date() expects parameter 2 to be int, string given in /home/ebon7ea8/public_html/pwsWD.next/temp_c_small.php on line 116

Warning: date() expects parameter 2 to be int, string given in /home/ebon7ea8/public_html/pwsWD.next/temp_c_small.php on line 118

The output from PWS_module_test.php for wind_c_small.php is:
Notice: Undefined index: winddir_avg2m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 346

Notice: Undefined index: windspdmph_avg10m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 461

Notice: Undefined index: winddir_avg10m in /home/ebon7ea8/public_html/pwsWD.next/PWS_livedata.php on line 477

Warning: date() expects parameter 2 to be int, string given in /home/ebon7ea8/public_html/pwsWD.next/wind_c_small.php on line 109

Warning: date() expects parameter 2 to be int, string given in /home/ebon7ea8/public_html/pwsWD.next/wind_c_small.php on line 111

Notice the same error (wind data) in testing both the temp and wind modules too…

2

I have no idea why you ask the same question as you did by mail which was IMHO answered completely. Maybe to much errors in my-english.

1. The “notices”
They occur as your Ambient data is different from what the livedata script expects. There are not much PWS_Dashboard=>Ambient users. And not all Ambient consoles deliver the same set of data items.
In your mail you also mentioned similar “notices” for your Meteohub website. These occur as the MH-clientraw is shorter then expected in 2021 for a correct clientraw.txt.

Thanks for bringing these notices to my attention. As explained in the mail, forget about them, notices talk to the programmers, not the user.I adapted the livedata yesterday after answering your mail. When my 24 hour test has been done it will be in the next update. No hurry as it are notices.

2. The warnings occur as there is no time-data for todays high/low in the history file. They signal a problem with your data. You are using a block which needs more data then it can get from your standard data file (Ambient or Meteohub).

3. The “small wind temp blocks”
That are now two “different” blocks in one.
They can show todays high-lows as in all previous releases, also as in your 2004 release.
But this setting is switched off by default as 80% want the other new display.
To switch back to the “old display” as it was in your 2004 release:
Set line 4 to comment in temp_c_small.php and wind_c_small.php It now reads:

$my_choice      = 'multi';              // day / month / year

Change it by adding a comment mark at the first position:

#$my_choice      = 'multi';              // day / month / year

If you want to use multi-levels, which is the “three line” display:

[ul][li]Your scripts need to assemble and maintain a history file as Ambient (and Metehub) do not deliver those data-items.[/li]
[li]Therefor you need station-cron running 24/7.[/li][/ul]

As long as you do not run a cron-job those “extra-data” items have their initial value. There is no error or problem, the display and the warnings are correct. In your case, they always display the same values as those values can only be generated by a cron-job you are not running.

You have a choice to make after you read the first post at No High/Lows, where is history and graphs data used for, and ? cron ?
The small block can behave as before, if that is sufficient, switch multi-line off.
If you want the new look, read the cron documentation and setup your cron-jobs.

Remember, cron-jobs do far more things, such as improving response times by pre-loading.

Wim

3

I have no idea why you ask the same question as you did by mail which was IMHO answered completely. Maybe to much errors in my-english.

No, please do not misunderstand. I was taking your advice that this may be something that others may have the same issue and it should be addressed in the forum, not via email. I posted my question here so you could answer it for myself and everyone else to see. I was trying to make amends for contacting you directly when I should have used the forum first.

Wim: thank you for your assistance and all that you do for those of us who use your wonderful dashboards.

4

I have more results to share, and I have made some progress. I have two different stations in different locations with different hardware but hosted via the same service. I was able to configure cron via cpanel for each of my sites, and one of the sites is running correctly, yay!

The new multi-line 3 line display appears to have correct data now that I configured a cron job.

My second site (and the more important one) is still having some issues, but I have cron configured exactly the same except the path to the PWS_cron_stationcron.php file. My cron entry is:
*/5 * * * * /usr/local/bin/php /home/ynau9ea5/public_html/pwsWD.next/PWS_cron_stationcron.php

The station URL is:

I’m sure it’s something where I’m being stupid again; do I need to delete the history.txt file so it can be recreated?
The data for the 3rd row (annual - 2021) appears to be correct, but the monthly and daily data are not showing.

Any suggestions on what I need to do to get the min/max daily and monthly working now?

5

As the cron, setup on my home network Debian 10 Container is running:

*/5 * * * * /usr/bin/curl --silent https://www.fitzbek-wetter.de/pwsWDxx/PWS_cron_stationcron.php?pw=MyPassword &>/dev/null

You can test/verify your https cron link simply by putting it into a Web Browser and you should get following return:

success files loaded + history was already valid + need upload to others + 0 uploads + no roll-over needed

Br,

Lemuba

@pwsdashboard As I remember from 2020…? The PWS_cron_stationcron.php was password secured in the link, but this seems not to be any more the case…?

See here:
http://discourse.weather-watch.com/p/540870

6

At both your sites the crons do not work correctly
http://6835ebonyoaks.com/pwsWD.next/history_popup.php
=> has data for today
==> but it is old data (timestamp greater than current time)
===> probably because someone tested the cron-job yesterday to see if there are errors visible

https://y-naut.net/pwsWD.next/history_popup.php
=> has never seen a cron-job

Solution 1:
To find the error you need to check in your cPanel how you get the cron-job responses returned, in an e-mail or a log-file
Then we can see what is happening. Example of such a message:
success files loaded + history was already valid + need upload to others + 0 uploads + no roll-over needed

Solution 2: Slightly better but more difficult than 1
If you can not find that, please try the wget or curl way of running a cron-job.
Then the link and internal positioning is as if you were using the browser.
Ask your provider how to specify that.

@lemuba (1 post back) gave an example (I removed the optional use of the password for now)

*/5 * * * *  /usr/bin/curl --silent http://6835ebonyoaks.com/pwsWD.next/PWS_cron_stationcron.php &>/dev/null

[b]This post [/b] gives an example for wget

*/5 * * * * /usr/bin/wget -O - -q -t 1 "http://6835ebonyoaks.com/pwsWD.next/PWS_cron_stationcron.php"

Solution 3:
Use a free external cron-server, that way it is exactly the same as running it in your browser.
All providers have a log-file of the last xx runs so you can check the results of the last runs easily.
Read more here https://pwsdashboard.com/documentation2012/11_cron.pdf

====== Other problems:
Please read about updates here: https://pwsdashboard.com/documentation2012/03_updates.pdf
You still have the errors in the scripts, please run
Check for updates => unzip the download and update the scripts
Check for updates => same procedure

Wim

7

Certainly it has the possibility of password checking. Strongly advised when you have posted the links.

At first download the checking-default is “false” => switched off in PWS_cron_stationcron.php

#-----------------------------------------------
#                       settings for this script
#-----------------------------------------------
#            should the cron do a password check
#
$use_password           = false; // true => password needed  false => no pw check

Wim

8

I think the answer was that I needed to apply updates. Once I applied the updates and enabled cron logging I see this:

Cron ynau9ea5@ahs4 /usr/local/bin/php /home/ynau9ea5/public_html/pwsWD.next/PWS_cron_stationcron.php
success files loaded + history recalculated + history saved + need upload to others + 0 uploads + no roll-over needed

for both of the sites. (the homedir is different for each of the messages, but they both show the same result)

I need to configure NWS alerts and the general layout, then everything should be done. Thank you for all the assistance.

I am seeing one odd bit of data, but I’ve looking around in the code so much I might have broke something unintentionally. I’m going to reload everything from scratch following my install/configuration procedure that I’ve been taking notes about. If I still see the odd data I’ll start another thread to address it.

Again, I can’t say Thank You! enough to @pwsdashboard for his support and to the rest of the community for their thoughts and suggestions.

9

I was able to create the history file via pwsWD/PWS_hist_recreate.php?pw=12345 but now I’ve noticed that nws-alerts aren’t working. I’ll start a new thread for that. minor config issue, resolved.

I’ve noticed that there is something odd with annual rainfall totals, the bottom left of the dashboard. The old version of the site shows a 2021 rainfall total of 7.87 in (I believe this is accurate) while the new version of the dashboard shows a 2021 rainfall total of 26.72 in (not accurate). This is for the dashboard:

old dashbaord:

new dashboard:

(my other site seems to be working correctly for rainfall totals)

10

WD has a habit of doing strange things with rain on the 1st of the month. I would wait and see if anything changes after midnight…

11

Old site history => Station weather history
Empty so only the station-data is used as loaded from Ambient.net

New site history => Station weather history
Contains calculated history, for rain the year value of 26.72 is used
If you use the PWS_hist_recreate.php script to generate the history and a value seems incorrect,
=> you can use the update history script ( PWS_hist_update.php?pw=xxxxxx ) to set it to a correct value.

Why / when do the scripts use the history:
FOSHK stations (also used by Ambient) often get a reset when new firmware is installed
=> the year-rain value starts counting in the station form zero again.

The scripts check if the current “year” station value is lower compared to the calculated history.

Wim