Ecowitt GW2000 second site

Hello and best Wishes for this new Year
after a long silence (May 2023) i decided to use the template again for my ecowitt GW2000 gateway station (Witt)

I think that the configuration on the data recovery side went well but (except) that I see the value th 15.1° which we find in the “Max-Min Temperature” header of the template (screnn)
an idea …? thnx

Hi bianco6650,

Also the best wishes for 2024 th and that we all will have much fun with our “weather”-hobby.

Those min-max values are kept recent with the cron-job which should run every 5 mintues.
You can inspect the values with the “Climatologie” pop-up in your “Conditions Actuelles” block.


1 Like

thnx For the cron task sorry (but I’m not very fresh :sweat_smile:) okay i

just planned… apart from that nothing else to execute in the template files via the ecowitt gateway so :)-

I have an ecowitt wh-57 lightning sensor in situ on my site
I see that it is possible to migrate the c_small block of the template header as I can see on this site

in what way on my first site (the one with WL Cloud Api v2 recovery) ?

thank you in advance and have a good rest of the day

Capture d'écran 2024-01-02 154709

Hi bianco6650,

You can add different lightning sensors to any PWS-Dashboard site
Boltek (upload file), WeatherFlow (API) or Ecowitt (Custom upload file)

Use PWS_easyweathersetup.php → Tab Devices
→ Lightning data using Nexstorm
WeatherFlow or Tempest device: general weather-data - lightning - UV-Solar
→ Use Ecowitt extra-sensors with another weather-program

  • → Do you want to use the lightning sensor?

When you have the data uploaded you can select the correct small block.


hello thank you Wim yes i have a WH57
the ./ecowitt/ecco_lcl.arr file is in another directory /www ftp
ecowitt station template okay

for the first site : FAMECK OURY SUD Home Weather Station (DWL version)

in my easysetup the correct settings (screnn) :no_mouth:

Have a good day,

For security reasons that URL-link will not work.
The scripts assume that the data-files are correctly uploaded (FTP) to the same web-server the scripts are running.

When they are in different sub-domains on the same web-server one can use"…/" addressing. if allowed by the hiosting-security rules (probably not)

This internal link goes two steps to the main-root (../../)
And then into your ecowitt website.

Easiest solution:
Just consider buying an extra GW1100. That way you have a “spare” uploading device for your main ecowiutt website.
You can have multiple GW1100/2000 devices and all devices listen to the same sensors and can custom-upload to different websites.

Advanced solution:
There are more advanced solutions, but for that you need an extra raspberry-computer inside your home. It seems for just 1 extra upload of 1 sensor a to costly solution.


:unamused: thank you for these technical explanations
i also have a GW1000 but used for another project comparing sensors/weather shelters … le custom est configuré pour une autre application …
relative to the GW2000 as we can see on the web-ecowitt screen I have a wh40
its rainfall is closer to my manual !
is it possible then to choose it instead of Wittboy and replace the data in the corresponding “c-block” ?

Hi bianco66050,

Currently your ecowitt-custom upload

    [dailyrainin] => 0.366
    [dailyrainin_pz] => 0.539

contains both rain-values.

For those users with two rain devices, the WS90 values are not used for rain.
Only if you instruct to do so in the receiving script in the pwsWD/ecowitt/ folder.

The PWS_Dashboard scripts are already using the WH40 values for your website.


I added on my customer manager, access to site A ( from site B (
site B, in addition to its own files, should access site A’s files
the path indicated in its PWS_easyweathersetup.php
but null doesn’t work any better on my side :(-
I used my debug console to try to understand the problem

re_hmm unless I’m mistaken, i notice that my block-rain (still) records the Witt rainfall data. and not wh40
(as is the case in the graph chart from WU)


I come back to the Ecowitt WH57 + lightning_station_small.php
the open_basedir is correct on my web provider’s side
which means :

  1.” authorizes “
  2.” authorizes “
    I still can’t display the small block in the dashboard
    contrary to the beginning, now the debug console of “valdefench57sgz” (A) no longer sends me error messages but the sensor is still clearly visible in the custom “sgz57-meteolive” (B)
    the path of the file to retrieve to display the “small block” is that entered in the configuration of the target site (A)
    unless I’m still going the wrong way on the right path because even with [./ecowitt/ecco lcr/arr] that doesn’t work either

although i continue to no longer see open_basedir restriction visible in the debug-console
which I also tested with the uoplad of the HP2551C where the lightning sensor is well listed for the latest data
that on my web provider’s side the open_basedir is correct for both sites
still no solution to understand in more detail the problem of the absence of the lightning_station_small.php block :expressionless:

ps/ especially when I see that it is possible on other user sites…what?
have a nice week end

edit_ you set the url to
check the log with errors (??)


Sat, 06 Jan 2024 11:20:31 +0000 = Ecowitt data received:
Problem-77: NO PASSKEY found.
Problem-101: Item in upload: with value between next brackets =><= is invalid
Problem-111: No data uploaded

I continue to block for the correct display of my lightning sensor according to the custom ecowitt and the corresponding small block on the api cloud v1 template
I saw that there was a file “ecco_key.arr” in my pwsWD/ecowitt/ folder
so i deleted it just like the pwsWD/ecowitt/ecco_stats.txt file
I then checked the URL :

Here the log with the errors on :expressionless:
and the raw data table :
:expressionless: :expressionless:

I am totally lost what you asre trying to accomplish.

Last time I tried to help you, you wanted

  1. to use the ecowiit.arr from your “easyweather” website in your “valdefench57sgz-website”
  2. You had made sure that “the open_basedir is correct on my web provider”

That should have worked out of the box.

As it seems that it is not working, I checked every cause that it was not working.
The livedata file contains the correct link to load the ecowitt file from another website.
First line is your main weather-data, next line is the first available extra data file

    [loaded_from] => /www/

The scripts have checked that the file is readable, otherwise the second line would not have been there.

The ecowitt file is then read, found to be a correct array and processed as proven by a “control” field in the weather-data array
[AQ_time] => 1704880327

But still no lightning data on your website.

So I had top compare your website-scripts used for this block with the correct distribution ones.

And I found that lightning is not working as someone (a gremlin? ) changed in PWS_livedata.php|01|2023-12-25 line 1940 from do we use ecowitt and do we use lightning
if ($load_ecowitt_option <> false && isset ($ecowittlightning) && $ecowittlightning == true) # lightning
to do we not use ecowitt and . . .
if ($load_ecowitt_option <> true && isset ($ecowittlightning) && $ecowittlightning == true) # lightning

If bianco66050 changes it back the lightning block should show correct values.


I found it strange that your template did not display the lightning sensor when it was listed on the ecowitt cloud
you told me that the recovery of the data could probably come from my supplier who might not authorize open_basedir for security reasons
I therefore approached him to confirm or deny
then I had a doubt: since the v2 cloud API was not functional for me (bad luck) and here I had 2 ecowitt gateways and an ecowitt wifi console so maybe
that this could interfere again so I did a third test with only the uoplad of the console (esayweather)
okay I do my manipulations, it still didn’t work I read the error logs using the debug console and YES I read that it was a problem with this livedata.php file
gremlin so it was me :joy:
I had to discover the mysteries of coding alone anyway and obviously I wasn’t at the top since I had edited the line 1940 but with the two variables “true” so YES it couldn’t work correctly
and as you rightly pointed out enjoy diwit Shakespeare ALL’S WELL THAT ENDS WELL