INTRODUCTION:
In another thread I was pointed to the location of the clientraw*.conf files.
They are the template files (with the [] tags) for the generation of the clientraw*.txt files.
I run into problems with the current version of the clientrawhour.txt file and want to modify the generation of that .txt file by replacing [seqmin15_sol0_radiation_wqm@1:-] with [seqmin15_sol0_radiation_wqm@1:0] in all 120 fields containing solar data.
Currently a '-' is used for a non-existent solar sensor value. Correctly from a programmers point of view, but the often used wugraphs fail to process the clientrawhour.txt when containing a - for those values.
Changing the *.conf files in the /home/meteohub/ folder only helps for a short period of time. Maximum to the next modification/save of the WD/MW live setup page. And maybe even the update of a new release will remove the changes made to the *.conf files.
QUESTION:
Is there a location known and user-accesible for the files which are used to generate the clientraw*.conf template files?
I want to
1. change the '-' for non-existenst solar data.
and
2. see if it is possible to extend the number of fields to the latest version of clientraw*.txt
Wim
extending adapting clientraw*.setup files
Moderator: Mattk
Re: extending adapting clientraw*.setup files
I can change "-" to "0" with the next update as I think it will not put any harm to other users.
The conf file is generated inside the Meteohub code, so no chance or user changes.
The conf file is generated inside the Meteohub code, so no chance or user changes.
- YJB
- Platinum Boarder
- Posts: 387
- Joined: Thu Feb 19, 2009 5:53 pm
- Location: Venhuizen, Netherlands
- Contact:
Re: extending adapting clientraw*.setup files
Hi,
I'm probably going to open a can of worms, but is "0" a good default value when there is no radiation readout? I'm not sure WD is using, but I think it will be difficult to differentiate between a -real- "o" and a "no reading "0". I do agree that "-" is causing problems, but that actually applies to all the "-" default values in the the WD files (not only the solar ones).
Ysbrand
I'm probably going to open a can of worms, but is "0" a good default value when there is no radiation readout? I'm not sure WD is using, but I think it will be difficult to differentiate between a -real- "o" and a "no reading "0". I do agree that "-" is causing problems, but that actually applies to all the "-" default values in the the WD files (not only the solar ones).
Ysbrand
Re: extending adapting clientraw*.setup files
I have to agree with Ysbrand. 0 is a perfectly legal value for a solar sensor.YJB wrote:Hi,
I'm probably going to open a can of worms, but is "0" a good default value when there is no radiation readout? I'm not sure WD is using, but I think it will be difficult to differentiate between a -real- "o" and a "no reading "0". I do agree that "-" is causing problems, but that actually applies to all the "-" default values in the the WD files (not only the solar ones).
Ysbrand
But the wugraphs are used on multiple websites and those scripts use the clientrawhour.txt to generate the last hour graphs.
Meteohub users who do not have a solar sensor can not use the hour graphs, WD users can.
If someone ask about this in a post on a forum and I see that post, I can send them a very slightly modified script which simply substitutes a zero for the - in the solar fields. But most users will have to skip the hour graphs.
I have to agree with that also. And we do not know where the Metehub versions of clientraw*.txt files are used for.I do agree that "-" is causing problems, but that actually applies to all the "-" default values in the the WD files (not only the solar ones).
Indeed for WD-live, in some scripts for realtime ajax values (Saratoga), for the hour graphs in wugraphs.
So changing ALL - values to 0 (WD seems to use a 0 always) can cause more problems than leaving everything as is.
Changing the - to 0 for the solar fields in clientrawhour.txt is a minor change and will hopefully not lead to unexpected side-effects. If so Boris will probably be kind enough to revert the code back to the old situation.
Wim