it may be advisable to first read the chapter on data flow (link) before delving into the data logger topic

Most Ecowitt consoles do not store historical data - or the historical data e.g. of the HP25x0 consoles or HP3500 consoles saved as CSV files on a microSD if inserted into the console cannot be directly accessed. An exception of some sort are the WS2320, the WS6006, the WS6210 and the GW3000 consoles. The WS2320 console stores the last 3.600 records internally and they can be retrieved via a communication program (WeatherSmartIP resp. WeatherSmart WiFi) from a Windows computer an can be stored in a MS Access database. The WS6006 stores data as CSV files on a microSD (if inserted) and it can be retrieved via a USB connection. The WS6210 and GW3000 also store the historical sensor data as CSV files on a microSD - these can be retrieved via network access.

These data logger and information broker programs often offer the forwarding of weather data to special weather networks like CWOP which do not accept the Ecowitt, Ambient or WU data protocol. Others are mainly used for Home Automation.

Therefore many people use data logger programs which retrieve the historical data from the console and store them in their own database from where they then can be further processed. See the most popular ones being used for Ecowitt (clone) stations below

• CumulusMX
• FOSHKplugin (Information Broker)
• HomeAssistant (Home Automation)
• Meteobridge/Weatherbridge
• PWT
• Weather Display
• weewx
• SDR RTL 433
• OpenHAB (Home Automation)
• HomeBridge / Apple Homekit (Home Automation)
• Meteotemplate - customized design and SQL database

Examples for websites based on these data logger programs can be found under https://meshka.eu.
In the Meteotemplate example the logged console data are again stored as 5-minute records in a SQL database (sort of double logging).
These websites can be hosted locally (PC, NAS, RaspberryPi …) and/or in the internet on a webhost.

also, be aware that your data is stored on ecowitt.net with a 5-minute resolution for 90 days only
see data retention on ecowitt.net
————————————————————————————————————————————————————————————————

PWT is an Android app (compatible with Android >= 4.0) to display data from Ecowitt consoles posted via the customized server function. It expects data in Ecowitt protocol, the default Ecowitt console customized server posting. With the exception of the WS6006 console which anyway post via 3G/4G mobile networks, all modern WLAN (or LAN) enabled Ecowitt consoles post in Ecowitt format.

PWT is an excellent possibility to repurpose an old Android tablet to display the weather data from a displayless console/gateway. Of course, also a modern tablet can be used and also consoles with display can post these data to an Android tablet on which PWT is installed an running, e.g. as a 2nd console display in a different room.

PWT can display all Ecowitt sensors with the exception of the WS90 sensor array rain data and the IoT devices. Reason for the inability to display rain data from a WS90 piezo rain sensor is, that the developer hasn't implemented this data yet and doesn't seem to further develop the software. The WS90 rain data issue can be circumvented by using the FOSHKplugin tool renaming the piezo sensor names into traditional rain sensor names.

The PWT display can be divided into seven different sections of different size which can be custom arranged. Also the background and font colours can be chosen. The right side areas can also show cycling sensors. The display language can be chosen.

below an example:
here the data is from a WS90 outdoor array and is received from a FOSHKplugin instance where the piezo rain data is converted into traditional rain data. The update interval has been chosen to be every eight seconds as this is also the transmission interval of the sensor array.

the area to the right cycles in the top portion between outdoor humidity and the dew point, between the WH41 (PM2.5) and WH45 (PM2.5, PM10, CO2) in the middle portion, WH51 (soil moisture) and WH31 (extra T/RH), WH45 T/RH and 2 x WN34 (user temp) and one WN35 (leaf wetness) in the lower portion.

Basically the PWT app displays all the sensors that a HP25x0 console also displays, including the WH57 (lightning detector) as it had been the reference for creating the display. The WH41/43, WH45, WN34, WN35 and WH51 sensors have a much better visibility in PWT than on a HP25x0 console display.

the PM2.5 of WH41 Ch1 and the CO2 graphs are displayed (other can of course be chosen instead)

as the app will no longer be further developed, it can be used to display rainfall from a WS90 piezo rain gauge only with the help of FOSHKplugin or a similar information broker software


the data to be entered to make your Ecowitt (clone) console post to PWT:

How to install PWT

1. download PWT from Google Play store (you will have to search with “PWT”) *
2. start PWT
3. a setup wizard will be offered - press “continue”
4. once set up the app should receive and display live data from your console
5. you can also press “settings” and walk through the shown tabs on top from left to right
6. you can try the different layouts and themes by visiting again the settings

*) PWT is no longer available at the Google Play store - the author has disappeared - the domain with the documentation is for sale - APK file is here: PWT.zip
regarding documentation: the inbuilt documentation is good and clear enough to get PWT properly running and customized.
————————————————————————————————————————————————————————————————-

CumulusMX also often referred to as CMX is a free-of-charge data logging and data display program which runs on several OS platforms like Windows, Linux and MacOS. It has been written under Windows and needs the .NET 8 (runtime library, actual version 8.0.14) to work. For the Linux and MacOS versions the “dotnet” library must be used (CMX V4 - until V3 it was the “mono” library). The latest .NET 8 runtime installer for x64 Windows systems can be found here (.NET 8.0.16 - May 2025)

The current versions (06-Mar-2025) and (28-Mar-2026) are 4.5.2 build 4128 and 5.0.0 build 5001
you can check the current version/release at CMX current version - if you run CMX in a console windows (see below), a message will inform you about the availability of a new version/release. Also, in the Administration interface, the bottom bar will show the version/release on every page. On the dashboard page of the Administration interface, there is a green dot at the bottom (text: Upgrade available) which will turn red and start blinking when a new version is available. If activated in the settings, also a sound will announce the availability of a new version once you visit the dashboard page.

There is a new release for CMX V. 5.0.0 build 5001 available (28-Mar-2026) This version needs the .NET runtime library 10
(.NET 8 doesn't suffice any more). CumulusMX 5.1.0 build 5004 will be available soon (May 2026).
The latest .NET 10 runtime installer for x64 Windows systems can be found here (.NET 10.0.3 - May 2025)

————————————————————————————————————————————————————————————

1. download the packed ZIP archive from the Cumulus WiKi
   (it will be something like CumulusMXDist4084.zip from https://cumuluswiki.org/a/Software chapter “Latest build distribution download”)
2. unpack the ZIP archive to where you want in your file system - a folder CumulusMX will be created
3. the folder name must not be changed - it must be CumulusMX. The location inside the file system doesn't matter. This applies to all OSs
4. from inside this folder start CMX:

The below example assumes that CMX was installed on drive C: - if you choose another drive, you have to change the drive letter in the below examples accordingly. For Linux/MacOS the /opt folder was chosen as parent directory for the examples used.

a) Windows in a terminal/console window

C:\CumulusMX> CumulusMX.exe

b) Linux or MacOS

# CMX version 3
/opt/CumulusMX $  sudo mono CumulusMX.exe
# CMX version 4 and 5
/opt/CumulusMX $ sudo dotnet CumulusMX.dll

This assumes that the mono or dotnet runtime library is already installed on your computer.
if you log in as user root, sudo won't be necessary
the path /opt/CumulusMX is an example - however, CMX always has to be launched inside the CumulusMX directory as it uses paths to other directories relative to the launch directory.
by default CMX uses the port 8998 for its communication - if this port is already in use or you want to run more than one CMX instance (see farther down), you have to explicitly enter the port number, e.g.

 C:\CumulusMX> CumulusMX.exe -port 8999 

When you run CMX in a console window (Windows, Linux), this windows has to remain open all the time. Once you close the console windows, CMX also stops.

———————————————————————————————————————————————————————————
running CumulusMX automatically at computer start-up/(re-)boot

When you want to have CMX automatically started at system startup, there are several options, depending on skill and knowledge of the operating system.

1. run CMX via a task scheduler (Linux: CRON, Windows; Task Scheduler)
2. run CMX as a service (Linux: service manager e.g. systemd, Windows via the Service Manager [services.msc] after having created a user defined service)

1. Linux
you have to edit the crontab file usually located under /etc (e.g. sudo nano /etc/crontab) and add the below lines on top of the file

# Start Cumulus as background task 30s after reboot (delay to allow WiFi to startup)
@reboot root (sleep 30;cd /home/pi/CumulusMX;sudo dotnet CumulusMX.dll) &

the path has to be adapted to your existing path to the /CumulusMX directory
the “&” will make the task run in the background - there will be no console window

1. Windows
Use the Windows Task Scheduler interactively and add a task

2. running CMX as a service is now easy with version 4

- for Linux, there is a description in the CumulusMX forum board Running CMX V4 as a service
in a terminal/console window - start CMX inside the CumulusMX directory with the -install option

pi@raspberrypi:/home/pi/CumulusMX dotnet CumulusMX.dll -install

- for Windows
in a terminal/console window - start CMX inside the CumulusMX directory with the -install option

C:\CumulusMX-V4\CumulusMX>CumulusMX -install
Restarting as elevated...
Cumulus MX is now installed to run as service
2025-05-26 14:28:19.164 Cumulus terminating
C:\CumulusMX-V4\CumulusMX>

Then CMX will run as an automatic service at computer start and can be managed via the Service applet (services.msc)

———————————————————————————————————————————————————————————

the CumulusMX Administration Dashboard
(you may see a point instead of a comma as decimal point depending on your locale [language and date/time settings])

CumulusMX (CMX) is a so-called open source data logger program which can receive or retrieve weather observation data from a console (or console emulation program like rtl_433), show the live data of the console as tables or graphs and store them in a user definded interval (default one minute) locally. In order to do this consistenly the program has to run 24/7.

The data is displayed on the Administration Dashboard in “real-time”, depending on the connected sensors and the driver used with a 5-second update/refresh. It adjusts to the shortest transmission intervall, for a WS80 that would be 4.75 seconds. If you use the http-post via the Ecowitt Customised Server feature, the shortest interval is eight seconds as this is the shortest posting interval for the Ecowitt Customised Server feature.

Meanwhile there are two version lines - version 3.x.x and version 4.x.x. Version 3 uses the Microsoft cross-platform library mono for non-Wndows installations, version 4 uses the dotnet library (see farther below)
Strictly following the IT wisdom “never change a running system”, many users who are happy with the functionality of their version 3 installation stay with it and don't have to go through the trouble of the data migration which especially for non-Windows installations can become tricky (see below).

If you start new with CMX, we recommend using version 5.

CMX is programmed under Windows and runs on Windows, Linux derivate or MacOS based computers. For non-Windows operating systems it needs/uses the mono runtime environment (Sponsored by Microsoft, Mono is an open source implementation of Microsoft's .NET Framework as part of the .NET Foundation and based on the ECMA standards for C# and the Common Language Runtime).

The latest versions are V.3: 3.2.6 build 3283 (03-Mar-2024) and V.4: 4.6.4 build 4128 (01-Dec-2025). There may be further upgrades since the last date documented here. V. 5.1.0 b5006 is available since 13-May-2026.

It also supports data history depiction and posting weather data to common weather network services like Weather Underground, Weather Cloud, Weather Observation Website (WOW), AWEKAS, CWOP, and many more including user defined data posts by the help of so-called webtags. It comes with a default website which can be hosted locally or with a web hosting provider and regularly updated by CMX via either FTP or a PHP script solution.
From version 4 on the .NET library used for Windows is > 8.3, for Linux and MacOS the dotnet runtime library is used.

It has its own user community built and maintained WiKi at https://cumuluswiki.org/a/Software

which is more of an experienced IT and CMX guys WiKi than a “CMX for Dummies” WiKi.
It may be difficult to read and understand for some (or more).
Even for me as an IT professional it is sometimes difficult to follow the CMX WiKi texts as the authors use a lot of implicit knowledge which is only known to the longterm expert and expect the reader to know that.
A common phenomenon not only in the IT field.
We have tried to explain the CMX features and the setup relevant for the Fine Offset/Ecowitt universe here in a hopefully better understandable way.

—————————————————————————————————————————————————————————

how to connect Ecowitt (or Ambient) consoles to CumulusMX (CMX)

As for Ecowitt (clone) consoles it can estabilsh the communication in three ways:

selection to be made in CMX (Settings –> Station Settings –> General Settings)

CMX V.3.28.6

CMX V.4.4.0

you first have to choose Manufacturer - Ecowitt and clones
then

Customized Server postings with Ambient or Wunderground protocol are hidden somewhere else in CMX V.4 - you have to choose the “Manufacturer” Ambient or Wunderground (didn't know that they were manufacturers) and there choose the station type “HTTP Sender (Ambient)” or “HTTP sender (Wunderground)”.

(1) CMX requests data via TCP/IP port 45000 (firewall rule has to exist)
you have to enter the IP address and MAC address of your console/gateway (can be found in the WS View Plus app)

(2) the console posts weather data, CMX receives
you have to enter the following data in your customized server page of your console - or have CMX do this for you

if you use Ambient protocol or Wunderground protocol, the path has to be
/station/ambient? or /station/wunderground? (with a trailing ”?” - with Ecowitt protocol there is no trailing ”?”)
do NOT put “http://” or “https://” in front of the IP address

(3) CMX retrieves data of the user's device earlier stored at ecowitt.net from there -
CMX station type “Ecowitt cloud”
get yourself an API and APP key from your ecowitt.net account and enter it in CMX under Settings –> Station settings –> Ecowitt Cloud Access API (where and how to create and get an APP and API key is described further down in section “the CMX backfill option from the Ecowitt Cloud” )

in all of the above station/interface options you follow the CMX Configuration Wizard as described below:

the user communicates with CMX via the administration interface (Dashboard) in their web browser via http://IP-address-of CMX-server:8998 e.g. http://192.168.1.12:8998
once connected a setup wizard leads you through the setup process (Settings –> Config Wizard)
( the communication via port 8998 has to be allowed in the computer firewall - under Windows a pop-up window appears at first contact to create this firewall rule to grant access - it is advisable NOT to click-away this windows in impatience what has often occurred and then the communication cannot be established - this applies when CMX runs under Windows in a console/terminal window - if for some reason you missed this initial grant, you have to set up a firewall rule manually in either the Windows firewall or in the firewall of your Antivirus program - incoming and outgoing traffic TCP/UDP for port 8998 has to be allowed - if for some reason you use another port for the CMX communication, you have to set the rule for this port)

Extra Sensors like WH31 (extra T/RH sensors), WN34 (user temperature sensors), WH35 (leaf wetness sensors), WH51 (soli moistures sensors), WH41/43 PM2.5 sensor, WH57 Lightning sensor and WH45 air quality combo sensor have to be activated and set to “visible” under Settings –> Display Options –> Data Visibility).

If you have a solar sensor (every Ecowitt array except the WN67 has a solar sensor), you have to activate its data display in Settings –> Display Options –> General Options): tag “solar” and “UVI”

If you have extra sensors, you have to activate their data logging and archiving (writing to CMX database) at Settings –> Station Settings –> Common Options –> Extra sensors. Otherwise they won't be saved and no historical data of the extra sensors recorded.

—————————————————————————————————————————————————————————

the CMX file system
to be upgraded for CMX V. 5 changes and introduced option (work in progress)

It can be helpful to know the CMX file system or directory tree and where CMX keeps files.
The central directory is ../CumulusMX (or ..\CumulusMX under Windows) - here is the main program CumulusMX.exe kept and the configration file Cumulus.ini (and, if you use CumulusUtils/CUtils also the cumulusutils.ini file).

With V.5 some of the directory locations can be user defined

• The path for the MXdiags files can now be specified in the CumulusMX.runtimeconfig.json file
• The paths for the data, backup, and reports folders can now be defined in Program Settings

The default locations are still as described below

We will describe the purpose and content of a few diretories, for further details look up the CMX Wiki (link above)

excerpt from the MXDiags log file

2024-03-15 09:30:00.150 Rotated log file, old log file was: 20240314-093000.txt
2024-03-15 09:30:00.150 DoLogFile: Writing log entry for 15.03.2024 09:30:00
2024-03-15 09:30:00.150 DoLogFile: max gust: 14,76
2024-03-15 09:30:00.150 DoLogFile: log entry for 15.03.2024 09:30:00 written
2024-03-15 09:30:00.150 Writing today.ini, LastUpdateTime = 15.03.2024 09:30:00 raindaystart = 215,80 rain counter = 217,00
2024-03-15 09:30:00.150 DoExtraLogFile: Writing log entry for 15.03.2024 09:30:00
2024-03-15 09:30:00.150 DoExtraLogFile: Log entry for 15.03.2024 09:30:00 written
2024-03-15 09:30:00.150 DoCustomIntervalLog: CSV-test - Writing log entry for 15.03.2024 09:30:00
2024-03-15 09:30:00.150 DoCustomIntervalLog: entry: 15.03.24;09:30;9,5;95;8,7;1017,5;20,5;52;4,48;14,76;NE;47;0,00;99,0;1,20;548;10,0;32,0;56;79;30;69
2024-03-15 09:30:00.165 DoCustomIntervalLog: CSV-test - Log entry for 15.03.2024 09:30:00 written
2024-03-15 09:30:00.165 Warning, previous web update is still in progress, second chance, aborting connection
2024-03-15 09:30:00.165 Trying new web update
2024-03-15 09:30:00.165 Interval: Creating standard web files
2024-03-15 09:30:00.165 Interval: Done creating standard Data file
2024-03-15 09:30:00.165 Interval: Creating graph data files
2024-03-15 09:30:03.275 Realtime[210]: Start cycle
2024-03-15 09:30:03.275 Realtime[210]: Creating realtime file - realtimegauges.txt
2024-03-15 09:30:03.275 Realtime[210]: Real time upload files starting
2024-03-15 09:30:03.556 Realtime[210]: Real time files complete
2024-03-15 09:30:04.119 Realtime[210]: End cycle
2024-03-15 09:30:06.415 Interval: Done creating graph data files
2024-03-15 09:30:06.415 Interval: Creating extra files
2024-03-15 09:30:06.415 Interval: Copying extra file ./utils/CUtagsT.php to /www/CUtils/CUtags.php
2024-03-15 09:30:06.415 Interval: Error copying extra file: Ein Teil des Pfades "/www/CUtils/CUtags.php" konnte nicht gefunden werden.
2024-03-15 09:30:06.415 Interval: Done creating extra files
2024-03-15 09:30:06.634 FTP[Int]: Error connecting ftp - Code: 530 Message: Sorry, the maximum number of clients (10) for this user are already connected.
2024-03-15 09:30:06.884 Reading live data
2024-03-15 09:30:06.884 DoCommand(CMD_GW1000_LIVEDATA): Valid response
2024-03-15 09:30:06.884 Received: FF-FF-27-00-A7-01-00-CD-06-34-08-26-9D-09-27-BF-02-00-5F-07-5F-0A-01-4D-0B-00-0A-0C-00-12-15-00-00-E4-20-16-00-00-17-00-2A-00-64-4D-00-40-51-01-40-4E-00-82-2C-38-2E-4F-30-1E-32-45-34-47-36-36-1A-00-5F-22-56-1B-00-69-23-5A-1C-00-60-24-5F-1D-00-64-25-5E-1E-FF-7C-1F-00-6C-27-4E-20-00-43-28-3C-59-00-62-00-00-00-00-61-65-0D-A9-96-60-0C-19-00-29-0E-00-00-10-00-0F-11-01-9B-12-00-00-01-B2-13-00-00-09-51-0D-00-0F-63-00-66-47-64-00-6C-4B-70-00-D0-33-00-27-00-1B-00-27-00-17-02-24-02-BB-06-72-63-6C-00-01-AC-30-4F
2024-03-15 09:30:06.884 WN34 channel #1 battery OK = 7,1V
2024-03-15 09:30:06.884 WN34 channel #2 battery OK = 7,5V
2024-03-15 09:30:06.884 WH45 CO₂: Decoding...
2024-03-15 09:30:06.884 WH45 CO₂: temp=20,8, hum=51, pm10=3,9, pm10_24h=2,7, pm2.5=3,9, pm2.5_24h=2,3, CO₂=548, CO₂_24h=699, Battery=DC
2024-03-15 09:30:06.884 LiveData: Wind Decode >> Last=3,6, LastDir=333, Gust=6,5, (MXAvg=4,5)
2024-03-15 09:30:06.884 DoWind: latest=6,5, speed=3,6 - Current: gust=14,8, speed=4,5
2024-03-15 09:30:06.884 DoWind: New: gust=14,8, speed=4,5, latest:3,6
2024-03-15 09:30:08.275 Realtime[211]: Start cycle
2024-03-15 09:30:08.275 Realtime[211]: Creating realtime file - realtimegauges.txt
2024-03-15 09:30:08.290 Realtime[211]: Real time upload files starting
2024-03-15 09:30:08.603 Realtime[211]: Real time files complete
2024-03-15 09:30:09.212 Realtime[211]: End cycle
2024-03-15 09:30:13.290 Realtime[212]: Start cycle
2024-03-15 09:30:13.290 Realtime[212]: Creating realtime file - realtimegauges.txt
2024-03-15 09:30:13.306 Realtime[212]: Real time upload files starting
2024-03-15 09:30:13.619 Realtime[212]: Real time files complete
2024-03-15 09:30:14.212 Realtime[212]: End cycle
2024-03-15 09:30:14.900 Reading live data
2024-03-15 09:30:14.900 DoCommand(CMD_GW1000_LIVEDATA): Valid response
2024-03-15 09:30:14.900 Received: FF-FF-27-00-A7-01-00-CD-06-34-08-26-9D-09-27-BF-02-00-5F-07-5F-0A-01-52-0B-00-0A-0C-00-12-15-00-00-DE-44-16-00-00-17-00-2A-00-64-4D-00-40-51-01-40-4E-00-82-2C-38-2E-4F-30-1E-32-45-34-47-36-36-1A-00-5F-22-56-1B-00-69-23-5A-1C-00-60-24-5F-1D-00-64-25-5E-1E-FF-7C-1F-00-6C-27-4E-20-00-43-28-3C-59-00-62-00-00-00-00-61-65-0D-A9-96-60-0C-19-00-29-0E-00-00-10-00-0F-11-01-9B-12-00-00-01-B2-13-00-00-09-51-0D-00-0F-63-00-66-47-64-00-6C-4B-70-00-D0-33-00-27-00-1B-00-27-00-17-02-24-02-BB-06-72-63-6C-00-01-AD-6C-AF
2024-03-15 09:30:14.900 WH45 CO₂: Decoding...
2024-03-15 09:30:14.900 WH45 CO₂: temp=20,8, hum=51, pm10=3,9, pm10_24h=2,7, pm2.5=3,9, pm2.5_24h=2,3, CO₂=548, CO₂_24h=699
2024-03-15 09:30:14.900 LiveData: Wind Decode >> Last=3,6, LastDir=338, Gust=6,5, (MXAvg=4,5)

———————————————————————————————————————————————————-

the CMX backfill option from the Ecowitt Cloud

when your console posts to ecowitt.net, five minute records will be created as average from the minute based postings (unless you choose 2,3,4,5 minutes as posting interval in the ecowitt.net Weather service page). These records can be downloaded by CMX if for some reason CMX did not run for a period of time (e.g. you shut down the computer CMX was running on over night).

A few prerequisites need to be taken into account:

1. create an API key in your personal ecowitt.net account (click on the avatar picture top right)
2. create an APP key in your personal ecowitt.net account
3. enter this information in CMX (Settings –> Station settings –> Ecowitt Cloud Access API)
4. make sure the MAC address of your console/gateway is also entered in CMX (you can find it in your ecowitt.net dashboard under “Devices” or in the WS View Plus app)
5. save the changed settings

(Settings –> Station settings –> Ecowitt Cloud Access API)
there are now two scenarios:

1. start CMX for the first time and download all 5-minute records from the past 90 days from ecowitt.net and then have CMX continue logging
2. your operation of CMX was interrupted in a later stage (e.g. shut down laptop over night)

(1)

• start CMX and configure it - the files today.ini and MMMYYlog.txt (e.g. Mar24log.txt) will be created
• when you have extra sensors and extra sensor logging switched on, ExtraYYYYMMLog.txt will also be created.
• stop CMX, delete the files MMMYYlog.txt (and ExtraYYYYMMLog.txt if existing)
• open ../CumulusMX/data/today.ini (..\CumulusMX\data\today.ini under Windows) with the Notepad or Nano editor
• change date and time in the top section to today minus 90 days
• save today.ini
• restart CMX

CMX will now start and then download the 5-minute records from ecowitt.net from the past 90 days. Once finished it will continue logging your weather data in the selected time interval (default is one minute). During the download the files MMMYYlog.txt, ExtraYYYYMMLog.txt, dayfile.txt and the record files will be updated.

assuming the first CMX run would be 03-Mar-2024; minus 90 days = 03-Dec-2023 the top portion of today.ini would look like

(2)
Just start CMX and CMX will start downloading the data from ecowitt.net after the last update of today.ini. Once completed, it will continue with normal logging.
———————————————————————————————————————————————————————————

the CMX backfill option from the GW3000/WS6210 SD card

from version 4.4.0 on CMX will also support the data backfilling of the CMX database (the CMX YYYYMMlog.txt and ExtraLogYYYYMM.txt files) in case of CMX downtime or local network issues.

for this the station type “HTTP local API” will have to be selected and the SD card checkbox tagged in the Station Settings.
when the SD card option is activated, the data from the SD card will be taken to fill the gap between the last database write (–> today.ini timestamp) and the actual time at a CMX restart.


the SD card option will not work with the “TCP local API” option (meanwhile renamed to “binary local API (legacy)”).
the CMX backfill from ecowitt.net (Ecowitt Cloud Access API in CMX terminology) and the SD card are mutually exclusive.
———————————————————————————————————————————————————————————

how to rename your Extra Sensors in CMX
you have to edit the file strings.ini in the …/CumulusMX directory
or, since version 4, using the “Locale strings” menu item in the Settings menu.

[ExtraTempCaptions]
Sensor1=WH31 DIY               
Sensor2=WH31 Greenhouse        
Sensor3=WH31-EP MetSpec Rad02  
Sensor4=WH31 Balcony           
Sensor5=WN30 Freezer           
Sensor6=WH31 Greenhouse (1m)   
Sensor7=WH31 Fridge            
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10

——————————————————————————————————————————————————————————————–

how to rename/remap your Extra Sensors in CMX

Ecowitt stations can now - from version 4.5.0 on - map the values from an Extra Temp/Humidity sensor to the indoor T/H values (previously only outdoor T/H mapping was implemented).

see Settings → Station Settings → Ecowitt Sensor Mappings

instead of the default setting for the Indoor or Outdoor T/RH sensor you can select the readings of any of the eight Extra T/RH sensors to be shown instead.

——————————————————————————————————————————————————————————————–

running two instances of CMX on the same server

if you want to run to instances of CMX on the same server (connected to the same console or to different ones), you will have to install CMX twice - there need to be two sepearate directorie by the name ..\CumulusMX (or ../CumulusMX), each with the complete installation.

example Windows
\CMX1\CumulusMX and \CMX2\CumulusMX
example Linux
/opt/CMX1/CumulusMX and /opt/CMX2/CumulusMX (you can make your own choice where to put the directories in the file system)

example Windows:
open two console windows (Windows + R –> cmd.exe) - move the input focus to the repective directory

C:>cd \CMX1\CumulusMX
C:\CMX1\CumulusMX> CumulusMX.exe            (normally under Windows it would be enough just to enter "cumulusmx")

in the second console window you enter # V.3 and V.4

C:> cd \CMX2\CumulusMX
C:\CMX2\CumulusMX> CumulusMX.exe -port 8999 

in both console windows CMX should start up
you can reach the Admin-Interface of instance 1 via http://IP-of-CMX-server:8998 or http://loalhost:8998 and
you can reach the Admin-Interface of instance 2 via http://IP-of-CMX-server:8999 or http://loalhost:8999

the choice of port numbers is free - as long as you don't choose a port already used by another application

under Linux or MacOS you will have to run CMX via the mono (CMX v.3) or dotnet (CMX v.4) library
under Linux or MacOS the CMX-V4 application run via dotnet is CumulusMX.dll (the dynamic link library) and not the executable file CumulusMX.exe
e.g.

pi@raspberrypi: /opt/CMX4/CumulusMX $ sudo dotnet CumulusMX.dll -port 8999

——————————————————————————————————————————————————————————————–

introduced changes with CumulusMX v. 4 (11-May-2024)

CMX v4 runs on Linux and MacOS under dotnet and no longer on mono. In Windows (usually) .NET is included.
- using v4 you will have to migrate your data to version 4 which also have a new naming pattern for the data files
- you can run your CMX v3 and CMX v4 in parallel on the same machine, v3 using mono and v4 using dotnet

installing Microsoft dotnet on a Linux computer, especially on a Raspberry Pi (ARM processor, 32-bit OS) is not a trivial thing.
A working procedure for getting dotnet installed on a RaspberryPi with a 32-bit Raspbian OS is
https://www.petecodes.co.uk/install-and-use-microsoft-dot-net-8-with-the-raspberry-pi/
it was successfully installed with the above script on a RaspberryPi 4B-8 GB OS Raspbian 10 (buster)

you may also want to read: https://cumulus.hosiene.co.uk/viewtopic.php?p=179794

General instruction on how to install CMX V4 on different operating systems (OS) like Windows, macOS, Linux derivates can be found at https://cumulus.hosiene.co.uk/viewtopic.php?t=22051

hint:
if you want to continue using your settings from version 3 and don't start from scratch, you copy your Cumulus.ini file from you old into your new …\CumulusMX directory.
if you are using the Ecowitt cloud backfill option, you will have to start CMX-V4 and then enter - your API key (from you ecowitt.net profile) - your APP key (from you ecowitt.net profile) - your MAC address (from your console, WS View Plus device list, WebUI network settings)
again and then save (!) and restart CMX.
Otherwise you risk to run into issues with the new encryption feature for credentials in CMX4

if you want to migrate your CMX4 installation later on, make sure the file UniqueId.txt from the ..\CumulusMX (…/CumulusMX) directory is also copied as all credentials in Cumulus.ini have been encrypted with the key contained in this file. This key is unique and belongs to your installation. Without it, CMX4 might not work after the migration.

New 4.0.0

• Moon Image now supports transparent shadows
• The -install/-unistall command line switches now support both Windows and Linux
• Under Linux run > sudo dotnet CumulusMX.dll -install -user <username> [-port <port_number>] [-lang <lang-code>]
• Windows install as a service now self-elevates and requests UAC
• Implements encryption of the credentials in the cumulus.ini file
• Experimental Gmail OATH 2.0 authentication
• New web tag for the average temperature of the previous 24 hours from now: <#TempAvg24Hrs>
• Cumulus backups are now zipped
• Add Enable option to Extra Web Files so you can now save entries but not have them active
• Ecowitt - added firmware update check on start-up and once a day at 13:00
• New Firmware Alarm to support this
• New web tag <#FirmwareAlarm>
• Adds new web tags for temperature means

• <#ByMonthTempAvg mon=[1-12]> Mean for requested month over the entire history. Omit the mon parameter for the current month
• <#MonthTempAvg m=[1-12] y=[YYYY]> Mean for the requested specific month. Omit the parameters for the current month
• <#YearTempAvg y=[YYYY]> Mean for the requested year. Omit the y parameter for the current year
• Add “MX calculates Sea Level Pressure”
• Applies to HTTP Ecowitt, HTTP Ambient, GW1000, Ecowitt Cloud, FO, Davis Cloud WLC stations
• When enabled, the pressure calibration is applied to the raw station pressure
• Check your station pressure (Absolute) calibration!
• Adds true Altimeter Pressure calculation to GW1000, Ecowitt HTTP, Ecowitt Cloud
• Check your station pressure (Absolute) calibration!
• Added localisation of records web tag date/time formats
• Now includes the AI2 dashboard interface (alternative Administrative Interface) as an option
• To access use: http://<cmx_IP_address>:8998/ai2/index.html

New 4.4.0 (March 2025)
backfill option from a GW3000 or WS6210 console SD card is possible when using the http API
Laser Distance sensor LDS01 supported


New 4.5.0 (May 2025)
WH31 T/RH sensors can be mapped to the WN32P/WH32B indoor T/RH sensor
(so far only mapping of WH31 –> WH32 outdoor/WN32 was possible)
the alternative Administrative Interface updated

Changed

• Now requires Microsoft .Net 8.0 rather than mono to run under Linux and MacOS
• All data files are now written/read as invariant - dayfile, monthly log files, extra log files, AirLink, and custom log files
• NOTE: Custom log files may require the user to alter their configuration to use comma separators and add the rc=y parameter to numeric web tags
• Monthly log files now renamed to “[yyyyMM]log.txt” to remove localised month name - and now sortable in the file system!
• Added MigrateData3to4 utility.
• Basic workflow:

  *         Clean install v4
  *         Copy v3 Cumulus.ini to root (the ..\CumulusMX directory version 4 has been installed into)
  *         Copy v3 /data and /Reports folders to v4 install
  *         Rename the /data folder to /datav3
  *         Run MigrateData3to4
  *         Done!

also, in CMX 4.x the naming of the different possibilities (“station type”*) to connect Ecowitt (clone) consoles has changed.

It is now differentiated between

1. HTTP local API (applicable to all consoles with the local Ecowitt API except for the GW1000 and WH2650)
2. binary local API (applicable to all local API enabled consoles published before November 2024;
   only new sensors released after end 2024 like the WH54/LDS01 are not supported any more)
3. HTTP Custom Server (a function to send data available by ALL Ecowitt consoles)
4. Ecowitt.net cloud (retrieving data posted erlier by the console to the Ecowitt Weather Cloud, ALL consoles can do this)

using the Ambient http or Wunderground http protocol posting via the Customized Server function is hidden somewhere else in CMX V.4 - you have to choose the “Manufacturer” Ambient or Wunderground (didn't know that they were manufacturers) and there choose the station type “HTTP Sender (Ambient)” or “HTTP sender (Wunderground)”.

Owners of Fine Offset legacy stations from the pre-Ecowitt era have got a separate station type (CMX speech “Manufacturer”) - that term is also easily misleading as Ecowitt is not a manufacturer. The manufacturer is FineOffset and its retail brand is Ecowitt. There are separate drivers (“stations”) for stations with solar sensors or using the EasyWeather software.

With CMX V.5 a new log file format (content, data sequence) will be introduced for the log files (the CumulusMX history databases for basic data and extra data)
when you upgrade from V. 4, you need to do a full backup (copy) of the V.4 CMX file system before starting CMX V.5 as the log files will be converted at first V5 start up and there is no simple way to go back.
(e.g. leave your old files in your now existing CumulusMX directory and create a new CMX5 directory into which you upack/install CMX5)

If you are a new user with no CMX data history, you can just unpack the archive into the directory of your choice and start CMX from within the CumulusMX directory.

suggested procedure:

• download the new CumulusMXDist5005.zip archive from GitHub or the Cumulus WiKi (file name may change with updates)
• create new directory …..\CMX5 (Windows) or …/CMX5 (Linux installations)
• unpack the archive into the …\CMX5 (resp. …/CMX5 directory - a subdirectory CumulusMX will be created and all files unpacked into it
• copy your version 4 data directory into the new file system
  e.g. xcopy -Y \CMX4\CumulusMX\data \CMX5\CumulusMX
• copy your version 4 Cumulus.ini file to your new CumulusMX directory
  e.g. xcopy \CMX4\CumulusMX\Cumulus.ini \CMX5\CumulusMX
• start your new CMX5 in a terminal Window to check the messages
  you can run it as a service once successfully running
• you can but don't need to keep your old V. 4 instances running - if so, you have give your new CMX5 a new port
  e.g \CMX5\CumulusMX\CumulusMX -port 8999 - otherwise the 2nd started instance will be self-cancelled

for Linux (derivate) user the respective command will be “cp -r -p /CMX4/CumulusMX/data /CMX5/CumulusMX”
your path may need to get accustomed - if you are not user root, you will have to put “sudo” in front of the command - under Linux or iOS your start command will be “dotnet CumulusMX.dll” (see also earlier in the introduction)
the corresponding Webtags for the WH52 and WN38 observations are also available.

the Charts menu has also been updated for the BGT/WBGT sensors (Temperature) and the WH52 Sensors (Soil Moisture / Soil Temperature).
The Soil EC (electrical conductivity) isn't supported yet. (CumulusMX 5.0.0 b5001 - supported from 5.1.0 b5004 on)


new 5.0 features in detail

• The path for the MXdiags files can now be specified in the CumulusMX.runtimeconfig.json file
• The paths for the data, backup, and reports folders can now be defined in Program Settings
• Custom Rollover MySQL commands now have the option to control being run during catch-up or not
• Adds LASER depth to the Dashboard Recent Charts, Recent Select-a-Chart, and Select-a-Period
• Adds LASER depth to the default web site Trends and Select-a-graph charts
• New .NET 10 versions of ExportToMySQL and CreateMissing (v3) compatible with MX v5.0 log file formats
• New script /MXutils/windows/CreateFirewallRules.ps1 for creating the required Windows firewall rules
• Add an exponential backoff to failed Email sends (up to 5.6 hours)
• New web tags <#snowunit>, <#CapacitorV>
• Adds a new Data Logs editor for the Recent Data from the SQLite database
• New option in Extra Sensor Settings under Laser Sensor Options to reset the current snow depth value being used for snowfall accumulation to the current laser depth value. This is used when there has been a large spurious change in the laser depth measurement for any reason. This does not affect the current snow depth measurement
• New Option in Extra Sensor Settings under Laser Sensor Options to specify if a laser is being used as a snow sensor
• Added ImportCumulusFile PHP script to /MXutils folder
• New Python script to upload monthly log files and the day file to MySQL - /MXutils/ImportCumulusFile.py
• Adds logging of debug snow data via the Program Settings > Logging Options - Logs to /data/debug_snowLog[sensornumber].txt
• Ecowitt HTTP Custom Server auto-configuration for main and extra stations now tries the HTTP Local API to access the station in addition to the TCP API (binary local API)
• Add support for BGT and WBGT to Ecowitt HTTP Local API, HTTP (Ecowitt), and the JSON stations
• New web tags <#BlackGlobeTemp> and <#WetBulbGlobeTemp>
• Two new fields added to the monthly log files and the monthly MySQL table to support these new measurements
• Add support for Ecowitt WH52 EC Soil Moisture Sensors to the Ecowitt HTTP Local API and HTTP (Ecowitt) stations - soil moisture and temperature readings only for now
• Fix ecowitt.net historic data download of PM measurements
• New snow depth filtering mechanism implemented. This is a three-stage filter…
  • Stage 1 applies a median filter to the raw values - you can specify the length of time in minutes for the median values. This is good for filtering out sudden spikes.
  • Stage 2 applies a clip to the output of the median filter. The clip limits the step size of the increase/decrease of the output of stage 1 to the value you specify
  • Stage 3 applies an Exponential Moving Average filter to the output of stage 2. This is essentially time based smoothing

• The default values are:
  Laser Units mm cm inch
  median (mins) 10
  clip (laser units) 1.0 0.1 0.04
  EMA time (mins) 12.0
  Note you can effectively disable any stage by setting: median=1, or clip=10, or EMA=0.1

Increasing the filtering also delays the value being updated. The approximate delay is median/1.5 + EMA time/1.5. The defaults will give a 10-12 minute lag

You can edit the new smoothing filter values in the Calibration Settings screen

Suggested starting Minimum Increments for the new filter: 2-5 mm, 0.2-0.5 cm, 0.08-0.2 inches

• Adds Snowfall 24h charts to the Dashboard and default web site
• Adds support for Ecowitt WH52 Soil Moisture sensors to HTTP API and Ecowitt.Net stations

————————————————————————————————————————————————————————————————- CumulusMX version 5.1.0 build 5006 (07-May-2026)
new features relevant for Ecowitt weather stations:

• High records added for BGT and WBGT values
• Additional BGT/WBGT fields to the end of the dayfile
• Adds support for Soil Electrical Conductivity to Ecowitt (shown on the Extra Sensors dashboard page and webtags)
• Adds support for the WS3900/WN1821 console built-in CO₂ sensor *

*) that option is a bit tricky how it is implemented in 5.1.0
While the WS3910 console can display the CO₂ (and air quality) sensor(s) of a WH45/46/46D AND the inbuilt CO₂ sensor data,
the inbuilt CO₂ sensor value is in CMX only shown when there is no WH45/46/46D connected - when there is a WH45/46/46D, the inbuilt CO₂ sensor value is NOT shown (this has to do with the fact, that in CMX internally only one variable for CO₂ exists [so far]). A feature request to show both values in case of a WS3910/WN1821 console has been submitted to the CMX developer.
For the WN1821 this also applies even though it cannot display the WH45/46/46D readings (but they will be available in the http API).

The full CumulusMX version 5 changelog (builds 5001-5006)

• CMX does not provide a lightning strike history, only the last strike time/distance information is provided
• CMX (or better the developer) does not consider solar radiation as worth being mentioned in the records page
  the existing maximum (theoretical !, not considring cloud-edge effects etc.) solar radiation in the solar chart is deemed sufficient information - a number of rather active CMX forum members maintains a strong opinion here.
  data logger programs like Meteobridge and weewx show history and records though …

Meteobridge (MB) was originally a piece of software which could (still can) be installed on certain routers to repurpose them as weather servers. Then only live data and maximum a two-day history could be shown as there was no possibility to store/archive data. This changed when the Meteobridge NANO SD was developed where now data could be saved on a microSD and a data history built. Then the Meteobridge Pro was introduced in two hardware editions: Red with the capability to receive the data directly via radio frequency from a Davis Vantage ISS (sensor array), and Black without that capability. It was/is (no longer produced as an hardware upgrade, the Meteobridge Pro2 is available now) equipped with 1 GB internal SLC USB storage for its database. (SLC = industrial Single Level Cell storage with high endurance). Meanwhile the successor model, Meteobridge Pro2 is available with a 16 GB SLC microSD card which could be upgraded to 128 GB

The Meteobridge Pro(2) is conceptualized as an appliance, a complete mini weather server (computer) easy to manage via a WebUI and a low energy and CO₂ footprint. It is also sold by Ambient under the name WeatherBridgePro2.

The Meteobridge software can also be installed as a combined OS (operating system) and application stack (the MB software) on a RPi3 or RPi4 which then has a much higher performance (needed when more than one station (up to 5 supported) with many sensors and a minute resulution is needed. Of course the energy consumption will then also be higher. For power users with 2-5 stations and many sensors beyond the basic observations solar, wind, rain, temperature/humidity the RPi platform is recommended. Not more than a 2GB RAM RPi is needed.
Images are available in the MB WiKi - link see below.

The official MB WiKi is somewhat small-lipped regarding the MB on RaspberryPi version, even though that's the most powerful installation. You only find it in the comparison table and the hardware section.
Even though there is a lot of information contained in the official MB WiKi, the special handling of Ecowitt (clone) consoles is not further elaborated - that's what you can find here.

Recently, May 2024, an option for installing Meteobridge on a few Hypervisor* platforms by the name Meteobridge VM has been published. That's a step in the right direction.

However, this solution doesn't cover by far all the most common Hypervisors - e.g. the probably most widely spread Microsoft Hyper-V is missing as if the IT universerve consisted of Linux derivate operating systems only. Why Windows users should use VirtualBox and cripple the use of WSL (Windows Subsystem for Linux) by deactivating Hyper-V, which comes inbuilt with every Win 10/11 Pro, as two hypervisors cannot run at the same time on the same hardware and is needed to run the WSL as a VM, remains a mystery.
Maybe the developer undergoes some enlightenment and a Hyper-V capable image will also be provided in the (hopefully near) future.

*) a Hypervisor is a special operating system which allows to share the server hardware resources with other common operating system installations as virtual machines (VM) e.g a MS Windows VM, an Ubuntu VM etc. One can also say it's “a process that creates and runs virtual machines”.

MB WiKi: https://www.meteobridge.com
MB forum: https://forum.meteohub.de

Meteobridge has inbuilt four different drivers for modern Ecowitt (clone) stations:

1. GW1000 (for consoles with the binary local Ecowitt network API)
2. GW3000 (for consoles with the local Ecowitt http API)
3. Ecowitt custom upload (for all consoles with the actual WiFi Firmware)
4. WH2350/WH4000SE (the Ecowitt WS2320 which has a special API - see there)

Beyond that drivers for legacy FineOffset models including the old ObserverIP (not ObserverIP 2.0 !) are available. The GW1000 drivers should also work with an ObserverIP 2.0 (WH2682) as it has the local Ecowitt API.



A WeatherBridge is the Meteobridge software on a re-purposed TP-Link router (re-)sold by Ambient under the Ambient brand .


The WeatherBridgePro2 is a MeteobridgePro2 appliance sold by Ambient.

The Meteobridge can be managed and its data viewed via a web browser interface (WebUI) under the IP address of the Meteobridge in the local network. Secure remote VPN connection via the Meteobridge VPN server (included in license) is also possible. Power users can access the Meteobridge via SSH (e.g. with PuTTY) on port 22.

Meteobridge exports part of its file system as a network share under Windows with the share name METEOBRIDGE.

REMARK: the 20-RPi and HDD directories are not part of the factory settings - they were added later

MB has a very powerful template language by which you can define exports, http-posts and charts.
some standard chart definition are provided, but MB comes with a chart composer module where you can design and build your own charts (Menu item Graphs –> Define Chart). An example of such a custom designed chart can be seen below.

below examples of the Meteobridge browser interface (http://IP-address-of-Meteobridge) -
(1) live sensor data -
(2) 2-day chart in minute resolution user defined -
(3) min/max values - daily and historical



———————————————————————————————————————————————————————————————

as one can see on the Live Data picture above, the current sensor readings come with a +/- cryptic abbreviation scheme which is unfortunately so far nowhere fully documented (except here now).
There are physical sensor names which are used with each station (#0; max # is 5 ⇒ stations #0 thru #4).
In the notation of the Meteobridge script language they follow the scheme:

e.g. th0!0temp (outdoor temperature), th0!1temp, th0!2temp, th0!2hum (Extra T/RH sensors 1-8), th3!0temp (outdoor temp station 4 - internal numbering 3 starting with 0)
if you want to view database data in the Database section or want to create your own scripts (tables, exports, graphs), you need to use these names.

There are also logical sensor names with a default mapping from the physical sensors, usually used for the the Primary station e.g. th0temp - in the Mapping table you can find an assignment th0!0temp –> th0temp.
these mappings can be changed if needed
the logical datanum sensors data0num thru data20 num usually have a mapping to the Primary station. If the physical sensor represents another existing sensor (e.g. LDS01) they are mapped to the virtual station #9, to show the Meteobridge device data e.g. CPU load

Below a translation table for the primary station #0

———————————————————————————————————————————————————————————————

this station type has to be chosen if you have a HP25x0 or HP350x or WH2910 console which do not have the local Ecowitt API
A WS2320 console has its own API which is also supported by Meteobridge
In MB it has the name “WH2350/WH4000SE”.

Otherwise you use the Customized server functionaility (see also Customized Server)
for the entries you have to make there see below

in ecowittn.cgi, the “n” is the number of your station in Meteobridge (MB supports up to 5 stations in parallel).
the primary station in Meteobridge is station 0 ⇒ ecowitt0.cgi
if your MB station for a Ecowitt console is station 1, then the name is ecowitt1.cgi etc.

Meteobridge offers the possibility to “rename” or better to re-assign your sensors.
In order to do so, you have to understand how sensors are named in Metobridge
Then you can use the “Mapping” page to do your re-assignment / mapping

there are two different types of sensors in Meteobridge: physical sensors and logical sensors
the physical sensors are the sensors per station Meteobridge receives, the logical sensors are what MB shows e.g. on the “Monitor” –> “min/max” page

the following table will show how things are related and what the acronym scheme is

……
remember that MB can manage up to 5 stations - therefore there will be (in principle) five outdoor temperature and humidity sensors: th0!0temp, th1!0temp, th2!0temp, th3!0temp, th4!0temp, th1!0hum, th1!0hum, th2!0hum, th3!0hum, th4!0hum etc

now, let's assume you want to cross-switch between your outdoor T/RH and your extra1 T/RH sensor, meaning: you want to show temperature and humidity from your extra temperatur/humidity sensor 1 as main outdoor temperature/humidity and the values from the official outdoor/temp sensor as extra1 temp/hum (of your primary station: station 0)

then you would do the following assignments:
th0!1temp = th0temp
th0!1hum = th0hum
th0!0temp = th1temp
th0!0hum = th1hum

on the mapping page you choose in the “select sensor” combo box [the to-be-mapped sensor] “th0!1temp” then a second combo box opens farther right [the mapped-to sensor]; there you choose “th0temp” - once the choice made a line in red appears in the table showing the new mapping - etc.

————————————————————————————————————————————————————————————————-

since MB version 6.2 the Aurora dashboard is available for all MB installations as a cloud solution. The Aurora dashboard orginates in the Weather34 dashboard by Brian Underdown which was no longer developed. Obviously the MB author managed to get the W34 developer to create this solution for Meteobridge which seems now to be station type independent. The original developer was adamant that only Davis station owner were supported - what, with some programming skills, could be circumvented and also Ecowitt sensors could be used.
The further development of now Meteobridge Aurora has been taken over by the Metobridge developer.

Already earlier the RaspberryPi, MB Pro2 and MB VM installations could use an Aurora type dashboard but without history data - just displaying realtime data and the data of the day. One had to tweak the php files to get also history data. This seems to be over now. At least history can be built from daily use, records (min/max) are taken from the MB database. If you want to include older history, it can be imported. The case where your history year files have a different format from what it is now is nowhere (except here) properly documented so far. For the procedure and structure see farther down.

The template files are also available for local (= not inside the Meteobridge cloud) installation:
Master installation
Upgrade installation

How the local realtime update will exactly work will still have to be figured out. Manually data can be downloaded. Possibly via some http posts out of Meteobridge as Weather34 Aurora (and predecessors) as it was called earlier was doing.

The dashboard is provided as a cloud solution in the Meteobridge cloud into which your data can be uploaded in a 40 minute interval. The primary setup is defining the Meteobridge Aurora Weather service. The dashboard itself has a lot more options, not all self-explanatory - a manual doesn't exist.
Forecasts and airport METAR data can be included when one possesses a WU and CheckWX API key.


the dashboard is accessed by clicking on the MB Aurora icon inside the Weather Network tile

The dashboard comes in nine (9) different template layouts (“skins”), the location of the tiles can be configured,





WU weather forecast



History Day

the data roll-over takes place at 00:00* local time (as configured in the settings)

History Month

the data roll-over takes place at 00:00* local time (as configured in the settings)

History Year

the data roll-over takes place at 00:00* local time (as configured in the settings)

*) if you have bigger database and have scheduled a backup for 00:00, the monthly and yearly rollup may be blocked - make sure that the time between 00:00 and 00:15 is free from scheduled events which block the Meteobridge database (like a backup)

as an example: I, @Gyvate, have a MB installation with four stations on a RaspeberryPi4B/2GB, one of the most powerful MB installations, and the backup is made via a USB3 port to a 2 TB HDD. Meanwhile the size of the database has grown over five years to 13 GB and its backup takes ~15 minutes during which MB stops its reading and data saving activity (even though in my opinion the data could be written to the sqlite database WAL (write ahead logging) file during the backup and then the database updated again - what doesn't take place.
May need a different programming or shifting the roll-over to e.g. 00:30 local time.) Then also the data for the MB Aurora dashboard are not available and also it seems that the resources used do not allow the roll-over PHP scripts to be run …
Maybe having the option for compressing the backup files as it is done in a Meteobridge VM installation, could be helpful here - enough local storage would need to be available for the creation of the archive.

CheckWx METAR data



In the non-accessible file system (cloud !) there is a folder …/weather34charts which contains yearly subfolders starting with 2019 and the yearly summary files 2019.csv thru …e.g. 2030.csv. The yearly CSV file is composed of the content of the month files (January.csv thru December.csv) contained in each yearly folder. Each yearly folder also the day files e.g. 1January2025.csv etc. which contain 5 minute data. An entry (record) in the month file is created at day roll-over based on the day file data. In parallel an entry is also created in the year file.

If you have downloaded and installed the local (=non-MB-cloud) solution on a webhost or a local (NAS, RPi) server and know how to read the php/html code, you can figure out the data structure details. Otherwise, see below.

For history display during a month, the respective month file is used. The daily history comes from the day file. Anything earlier than the current month is shown from the year file.

In the Admin Dashboard all the CSV (Comma Separated Value) files with the file system structure can be downloaded.

Missing data or data from an earlier installation where you had access to the files in the local Meteobridge installation, can also be uploaded. The download is made in a packed file format .tgz and the upload has to be the same packing format. Also the new structure has to be maintained.

When uploading old year files (2019.csv thru 2024.csv, respectively the partial 2025.csv file), you will before have to make the old files match the new file format. If it is too tedious to figure out the missing values, you can use a “–” instead (without “”) for an unknown or non-existing value - see example below - make sure that one record has 23 comma separated values.

The data structure of the montly and yearly files is like this:

a line (record) in the CSV file looks like this
14 May,27.7,8.3,8.9,3.1,0.0,5.4,1.2,**,1021.2,1017.8,5.0,946.0,0.0,20.4,77.0,77.0,21.0,0,–,–,–,–

If you happen to have the files from an earlier Weather34 Aurora installation, you can probably upload them without modification. If you are still using older versions, you can upload the files unmodified too, but then the humidity, wind direction and solar values will be missing in the history charts.

below a runbook how to import data you still have from earlier local or remote Weather34, W34-Aurora etc. implementations - assuming from 2020 thru 2025 and done on a Windows PC in the example
- install 7Zip to work on the .tgz archives - install the dashboard by activating the 30 second posting and then click on the MB logo in the weather station upload tile - the cloud dashboard opens - let it run for an hour or so to create entries for the current day - open the dashboard admin, do all the configuration - especially from what date on you have history data (afaik needed for getting the folders created) - save - go again into menu, dashboard Admin, there the first option is download the data files - download the files - an archive named “aurora-archive-YYYYMMDD.tgz” will be downloaded into your browser download folder - right-click that file and open it with 7zip (with the 7Zip File Manager) - click on the archive entry and the whole file system structure will be presented - now drag and drop the 2020.csv, thru 2025.csv files into the archive (root level - not into any directory) - go to the 2025 directory (double-click) - drag your current May.csv file there - close the 7Zip Manager and thereby save the new content - in the dashboard Admin select your downloaded and updated archive for upload and click upload - the files in the cloud will be overwritten with that content - and you will be able to see the data in the respective years
————————————————————————————————————————————————————————————————-

(that feature will also work with the Ambient WS-2000-ARRAY (WH65), the WS-1965-ARRAY (WN67),
the WS-4000-ARRAY (WS90) and the WS-5000-ARRAY (WS80) [plus the 5kRAIN/WH40 sensor])

this works with Meteobridge PRO red, PRO2 or an installation equipped with Meteostick* and the MB application software V. >= 6.2
the WS90 has an inbuilt pressure sensor (hence 8-in-1 ) whose information is transmitted via the RF protocol but not processed by console firmware.
For correct MSLP (mean sea level pressure) the altitude of the WS90 has to be entered as station altitude in Meteobridge.

*) Meteostick is a sub-GHz ISM Band receiver USB stick which can be connected to Meteobridge appliances which do not have that hardware inbuilt but have a USB port - Meteostick could already receive the data of the WH24 array (the “boat”) a.k.a. WH10xx station array.

With Meteostick firmware version >= 3.1 or Meteobridge PRO2 RF firmware version >= 2.1 also the RF signal of a WS80 array can be recognized directly. The station model to be chosen is now “Meteostick WS90/WS80”. Entering the sensor ID is analogous to the WS90 described above.

when using this feature to its full extent (i.e. eight [8] outdoor arrays) the Meteobridge Pro2 reaches its performance ceiling. Any further station added will put such a load on the MB Pro2 that it can no longer cope with the processing. So you either need another MB Pro2 (not a cheap option though) or use a Meteobridge on RPi4B installation together with a Meteostick if you want to run several Ecowitt outdoor arrays as one station and have more stations to integrate.

————————————————————————————————————————————————————————————————-

the new Meteostick RF readout driver for Ecowitt outdoor arrays allows up to eight different (=different sensor ID) arrays in parallel with one station to be connected and their data displayed

example:

• #0 00a794 (WS90)
• #1 00007c (WS69)
• #2 002a77 (WS85)

(N.B. it could also be three different WS90 or WS69 etc., just up to eight (#0 - #7) with different sensor IDs)

logfile (System –> Logging)

logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), channel 0 bound to sensor ID: 00a794
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), channel 1 bound to sensor ID: 00007c
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), channel 2 bound to sensor ID: 002a77
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), debug off
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), verbose off
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), output raw
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), rx threshold set to -90db
logger (18.06.2025 20:30:53): station 0 (Meteostick WS90/WS85/WS80/WS69), frequency band 868MHz (EU) WS90/WS85/WS80/WS69
logger (18.06.2025 20:30:59): station 0 (Meteostick WS90/WS85/WS80/WS69), channel 2 WS85 firmware version: 107
logger (18.06.2025 20:31:00): station 0 (Meteostick WS90/WS85/WS80/WS69), channel 0 WS90 firmware version: 156

live data view (page)

• Sensor #0 WS90: Outdoor (temp/hum), Wind, Rain, UV, Solar, Data (rainflag), Data#10 (battery voltage), Data#20 (supercap voltage)
• Sensor #1 WS69: Outdoor#1 (temp/hum), Wind#1, Rain#1, UV#1, Solar#1, Data#1 (rainflag)
• Sensor #2 WS85: Outdoor T#2 (temp only), Wind#2, Rain#2, Data#2 (rainflag), Data#12 (battery voltage), Data#22 (supercap voltage)

When you want to address a single sensor measurement template variable, this works as follows:

• Outdoor temp of Sensor #1 (WS29): “th0!1temp”
• Rainflag of Sensor #2 (WS85): “data0!2num”
• Wind speed of Sensor #1: “wind0!1wind”

a preceding “0” before the “!” indicates that this is data from the primary station, as Meteobridge can be connected to up to five stations via different drivers (in MB called stations) which will then be enumerated before the “!”.
Like this Meteobridge can handle many sensors from many weather stations from different vendors in parallel.

Station #9 is collecting system data from the Meteobridge. This station is automatically started and does not need manual configuration.

Assuming somebody has one WS69, two WS80, one WS85 and three WS90 arrays (together 7) within the reach (reception range) of the Meteobridge or the Meteostick, then the data of all seven arrays can be shown as one station and its data used in reports and graphs.
So far for such an approach different stations (consoles were needed)
for all the extra sensors and a WN32 and WN32P sensor, one gateway would be needed and be sufficient !

below an excerpt from the MB system log:


also single sensors e.g. WH51, WH31 family, WN34 can be received - but the whole number of receivable sensors is limited to eight (8)!
for the WH31 family sensors one can see the channel number in the log named “(user ch #)”

————————————————————————————————————————————————————————————————-

pre-requisite:
an import file with the supported data formats has to be put into the \\METEOBRIDGE\data\import directory
the available import formats are

• Meteohub Raw Data
• Meteoplug Export
• Meteotemplate
• Cumulus
• weewx
• WSWIN
• direct

I (@gyvate) am running two separate MB instances on two separate RPi4B computers. Sort of a live-RAID1 configuration.
The data is mirrored as the MB instances receive the same sensor data in parallel. The RPi4Bs are LAN cable connected to avoid wireless network issues - the consoles/gateways (2 x GW1000 = 2 MB stations are WLAN connected).
The sensors connected to the gateways are exactly the same. In case one gets stuck, the other station (and instance) still receives the data.

To import the data of one MB instance into another, the data needs to be exported. I have created an export template which creates minute based data triplets for each sensor (EPOCH date, sensor name, sensor value).
In fact, the resolution is not part of the template but can be chosen on the export page.
this file (content see below) is saved as a text file with the extension .exp in the \\METEOBRIDGE}data\export directory

# modified Standard CSV template with data in metric units
#
$# date,time,temperature[C],humidity[%],intemp[C],inhum[%],dew point[C],sealevel pressure[hPa],abspress,avg wind speed[m/s],gust speed[m/s],winddir,rainfall[mm],Solar [W/m2],UVI,PM25(1),PM25(2),extra-temp1 [C],extra-hum1 [%],extra-temp2 [C],extra-hum2 [%],extra-temp3 [C],extra-hum3 [%],extra-temp4 [C],extra-hum4 [%],extra-temp5 [C],extra-hum5 [%],extra-temp6 [C],extra-hum6 [%],extra-temp7 [C],extra-hum7 [%],extra-temp8 [C], extra-hum8 [%],soil moisture (1) [%],soil moisture (2) [%],soil moisture (3) [%],soil moisture (4) [%],soil moisture (5) [%],soil moisture (6) [%],lightning last occurrance,lightning distance,lightning total,WH45-temp-in,WH45-hum-in,WH45-CO2,WH45-PM25,WH45-PM10, WH34-1, WN34-2, WN35-1
[epoch] th0temp [th0temp-max:]
[epoch] th0hum [th0hum-max.0:]
[epoch] thb0temp [thb0temp-max:]
[epoch] thb0hum [thb0hum-avg.0:]
[epoch] th0dew [th0dew-avg.1:]
[epoch] thb0seapress [thb0seapress-avg.1:]
[epoch] thb0press [thb0press-avg.1:]
[epoch] wind0avgwind [wind0avgwind-max.1:]
[epoch] wind0wind [wind0wind-max.1:]
[epoch] wind0dir [wind0dir-avg.0:]
[epoch] rain0total [rain0total-sum.1:]
[epoch] sol0rad [sol0rad-max.2:]
[epoch] uv0index [uv0index-avg.1:]
[epoch] air0pm [air0pm-max.2:]
[epoch] air1pm [air1pm-max.2:]
[epoch] th1temp [th1temp-avg.1:]
[epoch] th1hum [th1hum-avg.1:]
[epoch] th2temp [th2temp-avg.1:]
[epoch] th2hum [th2hum-avg.1:]
[epoch] th3temp [th3temp-avg.1:]
[epoch] th3hum [th3hum-avg.1:]
[epoch] th4temp [th4temp-avg.1:]
[epoch] th4hum [th4hum-avg.1:]
[epoch] th5temp [th5temp-avg.1:]
[epoch] th5hum [th5hum-avg.1:]
[epoch] th6temp [th6temp-avg.1:]
[epoch] th6hum [th6hum-avg.1:]
[epoch] th7temp [th7temp-avg.1:]
[epoch] th7hum [th7hum-avg.1:]
[epoch] th8temp [th8temp-avg.1:]
[epoch] th8hum [th8hum-avg.1:]
[epoch] th20hum [th20hum-avg.0:]
[epoch] th21hum [th21hum-avg.0:]
[epoch] th22hum [th22hum-avg.0:]
[epoch] th23hum [th23hum-avg.0:]
[epoch] th24hum [th24hum-avg.0:]
[epoch] th25hum [th25hum-avg.0:]
[epoch] lgt0energy [lgt0total-nonzerotime=epoch:]
[epoch] lgt0dist [lgt0dist-lastval.0:0]
[epoch] lgt0total [lgt0total-dmax.0:0]
[epoch] th9temp [th9temp-avg.1:]
[epoch] th9hum [th9hum-avg.1:]
[epoch] data4num [data4num-avg.0:]
[epoch] air4pm [air4pm-avg.1:]
[epoch] air5pm [air5pm-avg.1:]
[epoch] t0temp [t0temp-avg.1:]
[epoch] t1temp [t1temp-avg.1:]
[epoch] th40hum[th40hum-avg.0:]

running this export from the Database –> Import/Export page creates the below file (excerpt)

# date,time,temperature[C],humidity[%],intemp[C],inhum[%],dew point[C],sealevel pressure[hPa],abspress,avg wind speed[m/s],gust speed[m/s],winddir,rainfall14,Solar [W/m2],UVI,PM25(1),PM25(2),extra-temp1 [C],extra-hum1 [%],extra-temp2 [C],extra-hum2 [%],extra-temp3 [C],extra-hum3 [%],extra-temp4 [C],extra-hum4 [%],extra-temp5 [C],extra-hum5 [%],extra-temp6 [C],extra-hum6 [%],extra-temp7 [C],extra-hum7 [%],extra-temp8 [C], extra-hum8 [%],soil moisture (1) [%],soil moisture (2) [%],soil moisture (3) [%],soil moisture (4) [%],soil moisture (5) [%],lightning last occurrance,lightning distance,lightning total,WH45-temp-in,WH45-hum-in,WH45-CO2,WH45-PM25,WH45-PM10,WN34-1,WN35-1
.........
1771955520 th0temp 11.3
1771955580 th0temp 11.3
1771955640 th0temp 11.3
1771955700 th0temp 11.3
1771955760 th0temp 11.3
1771955820 th0temp 11.3
1771955880 th0temp 11.3
1771955940 th0temp 11.3
1771956000 th0temp 11.3
1771956060 th0temp 11.3
1771784040 th0hum 97
1771784100 th0hum 97
1771784160 th0hum 97
.........

export file = raw import file
trying to import that file into Meteobridge with the direct format as-is will fail
the reason is that the sorting of the records is by sensor name - once the first sensor is imported, the time stamp starts again from the start of the export period - however, MB expects the time stamps to be ascendant.
the solution is to sort the exported data by time stamp (e.g. importing the export file into Microsoft Excel and then sort each line by time stamp)
sorted import file: (will be successfully imported with the file type option “direct”)

# date,time,temperature[C],humidity[%],intemp[C],inhum[%],dew point[C],sealevel pressure[hPa],abspress,avg wind speed[m/s],gust speed[m/s],winddir,rainfall14,Solar [W/m2],UVI,PM25(1),PM25(2),extra-temp1 [C],extra-hum1 [%],extra-temp2 [C],extra-hum2 [%],extra-temp3 [C],extra-hum3 [%],extra-temp4 [C],extra-hum4 [%],extra-temp5 [C],extra-hum5 [%],extra-temp6 [C],extra-hum6 [%],extra-temp7 [C],extra-hum7 [%],extra-temp8 [C], extra-hum8 [%],soil moisture (1) [%],soil moisture (2) [%],soil moisture (3) [%],soil moisture (4) [%],soil moisture (5) [%],lightning last occurrance,lightning distance,lightning total,WH45-temp-in,WH45-hum-in,WH45-CO2,WH45-PM25,WH45-PM10,WN34-1,WN35-1
1771784040	th0temp	9.8
1771784040	th0hum	97
1771784040	thb0temp	19.8
1771784040	thb0hum	55
1771784040	th0dew	9.3
1771784040	thb0seapress	1023.6
1771784040	thb0press	989.9
1771784040	wind0avgwind	2.2
1771784040	wind0wind	2.2
1771784040	wind0dir	221
1771784040	rain0total	0.0
1771784040	sol0rad	0.00
1771784040	uv0index	0.0
1771784040	air0pm	10.00
1771784040	air1pm	10.00
1771784040	th1temp	9.8
1771784040	th1hum	94.0
1771784040	th2temp	10.0
1771784040	th2hum	91.0
1771784040	th3temp	9.7
1771784040	th3hum	95.0
1771784040	th4temp	9.9
1771784040	th4hum	97.0
1771784040	th5temp	-16.3
1771784040	th5hum	
1771784040	th6temp	9.8
1771784040	th6hum	95.0
1771784040	th7temp	9.4
1771784040	th7hum	53.0
1771784040	th8temp	
1771784040	th8hum	
1771784040	th20hum	53
1771784040	th21hum	65
1771784040	th22hum	59
1771784040	th23hum	100
1771784040	th24hum	64
1771784040	th25hum	53
1771784040	lgt0energy	
1771784040	lgt0dist	0
1771784040	lgt0total	0
1771784040	th9temp	18.5
1771784040	th9hum	59.0
1771784040	data4num	816
1771784040	air4pm	13.9
1771784040	air5pm	13.9
1771784040	t0temp	9.4
1771784040	t0temp	9.9
1771784040	th40hum	
1771784100	th0temp	9.8
1771784100	th0hum	97
1771784100	thb0temp	19.8
1771784100	thb0hum	55
1771784100	th0dew	9.3
............................

General remarks: During an import the database is locked and no database updates take place (even though the data should be saved to the WAL (Write ahead log) file of the sqlite database. This somehow doesn't always work. The larger the import, the longer it takes and the longer the database is blocked.

Newer versions of Meteobridge (>6.0) allow an export in SQL import format - that's the only way to import data across platforms (e.g. MB Pro –> MB RPi or MB Pro –> MB VM etc.) beyond the import in direct Meteobridge format.

————————————————————————————————————————————————————————————————-

the latest platform for the Meteobridge software is the installation in a virtual machine (VM)
for details see: Meteobridge VM

- MB VM can be installed (so far - February 2025) on an amd64 (x86-64bit) platform only, no arm or other architectures.
- supported VM images are of the VMware, VirtualBox, KVM, PROXMOX type.
- in the Virtualization Station of a QNAP NAS with QTS operating system, a VMware .vdmk image can be converted into a .img by QTS and used. The .img from the .vdmk conversion is different from the .img provided as KVM image !
- image sizes are 16 GB and 128 GB
- the backups are stored as a packed .gz file in the new /tmp/mnt/data/backup directory locally and can be transferred via SSH
- migrations from other MB platforms (Nano SD, Pro, Pro2 or RaspberryPi can only be made using a SQL data export and SQL data re-import
————————————————————————————————————————————————————————————————-

Weewx
work in progress - to be completed

especially the section on local http API driver (drafted by Gary Roderick and finalized by Werner Krenn and Ian Milliard) and related information (unit definitions in extensions.py, new, complete database schema for Ecowitt (clone) weather stations whose consoles/gateways possess the local http API needs to be reworked.

basically, in weewx.conf a new station (station = EcowittHttp, a new respective driver section [EcowittHttp] and the new driver to use itself ( driver = user.ecowitt_http), a new database schema: schema = user.wview_ecowittrssi.schema and its definition, and the use of a customer units definition file extension.py have to be newly described, edited, modified, updated … as will have to be the below sections

when time allows …

Even though in principle the above sentences already contain everything, they need imho to be put in a more detailed presentation for the non-weewx-adept also to understand and benefit. Appreciating the good will of the creators of the official weewx documentation, it took me as a 30+ year IT expert quite some time to get to the ground of it and understand the concepts and the wording. I hope that the end product will be useful for the non- or not-yet weewx adepts to make that excellent piece of software running to serve their purpose and needs in the Ecowitt ecosystem.

Just as side remark - I recently read the comment of a another 30+ year UNIX/Linux OS adept in the weewx user group complaining that this WiKi was difficult to read - mmmh - yes, it's not written in bash script and Python code.

introduction and overview
weewx is a very powerful and sophisticated piece of open source weather software which has just reached its version 5 release (January 2024). The main developers are in alphabetical sequence Tom Keffer, Gary Roderick, and Matthew Wall. With its complexity also comes the need for a certain depth of knowledge of the Linux (derivate) operation system and services. It comes with a core functionality of processing and archiving weather data and provides an interface for drivers and extensions related to special weather station hardware. Many such extensions and drivers are available to cover the wide range of nowadays existing personal weather stations and/or sensors. Weewx runs on MacOS or a Unix/Linux derivate OS - on Windows 10/11 only inside WSL (Windows Subsystem for Linux which basically an Ubuntu Linux installation).

if you are new to weewx and/or not a Linux expert, we recommend to take the patience to read through the whole text here - the smaller the likelihood of making mistakes which can be difficult to spot will be

for the modern Ecowitt (clone) consoles and their available sensors four Ecowitt related drivers are important:

1. the Interceptor driver written by Matthew Wall
2. the Ecowitt local binary gateway API driver (a.k.a. GW1000 driver) written by Gary Roderick
3. the Ecowitt local http gateway API driver almost completed by Gary Roderick and under completion by Werner Krenn (November 2025)
4. the MQTT Subscribe driver/extension using the Ecowitt customized server feature with MQTT protocol

The interceptor driver is no longer maintained - alternately you can use the ecowittcustom driver based on the original interceptor driver and extended by Werner Krenn:
Download and documentation from GitHub ecowittcustom driver

as even whole repositories have disappeared from GitHub,
the Ecowittcustoms README.md file (October 2025) can be downloaded here - link

all what is written below about the interceptor driver can be 1:1 applied to the ecowittcustom driver
(the difference lies in the number of sensors and types of observations and information supported - interceptor only basic sensors - ecowittcustom all available sensors posted via Ecowitt or Wunderground protocol)

The Interceptor driver uses the data posted by Ecowitt consoles via the customized server functionality.
The Ecowitt local binary gateway API driver uses the application programming interface available with
the GW3000, GW2000, GW1000/1100/1200, WN1900/1910/1920/1980, WN1820/1821, WH2650 (WH2682), and WS3800/3900/3910 consoles
the Ambient WS-1965 (Ecowitt WN1920) and the ObserverIP 2.0 Hub/module (Ecowitt WH2682) also have this API

It does, however, not cover the full sensor range available today and is not further developed by Ecowitt
Hence, for full sensor support the local http API will be need to be used

the local http gateway driver supports all existing Ecowitt sensors. It does, however, not work with the GW1000/WH2650/WH2650 consoles/gateways as they don't have the local http API

For details regarding the Interceptor driver (basic version) and background information see https://github.com/matthewwall/weewx-interceptor - for the Ecowitt console specific setup see below Interceptor
For details regarding the Ecowitt binary Gateway API driver and background information see https://github.com/gjr80/weewx-gw1000/wiki
For unknown reasons this link is no longer available - you can get the latest driver version from
local binary API driver a.k.a. GW1000 driver


the official weewx documentation (version 5) is available at https://www.weewx.com/docs

While the API driver uses the full bandwidth of existing Ecowitt sensors and sensor arrays, the Interceptor as available at GitHub (March 2024) only covers the basic sensors (wind, rain, solar, indoor/outdoor temperature/humidity). For all other sensors the Interceptor driver needs to be modified/extended by the user (or get an extended version developed by other users).

It appears that in 2020 (last update of the Interceptor driver on GitHub) the GW1000 API driver wasn't available yet as the Interceptor was then (and still is as the documentation hasn't changed) offered as a driver for the FineOffset/Ecowitt GW1000 gateway using its custom server functionality. Given that when the GW1000 was released by Ecowitt, it supported already many other extra sensors, it remains a mystery why the limitation to the basic sensors was maintained. Especially as the HP2550 console which doesn't have the local gateway API did already exist and also supported many more than the basic sensors. That's when some users started to extend the Interceptor driver code and related configuration files to support ALL available non-IoT sensors. Possibly due to a focus on Davis and other more US based brand models, Fine Offset/Ecowitt was still considered “JBOD” and the success of the brand due to affordable prices, considerable quality, excellent customer service and a large variety of sensors was unexpected.

A similar and connected situation exists with the data which can be stored/archived in the weewx database. A relational database comes with a so-called database schema, a table-like description of all the different fields used in the database. For weewx there are two database schemas provided: the (legacy) wview and the wview_extended database schema, the latter based on the sensors available for a Davis VP2.
Even though there are fields in the wview_extended database schema which are not (yet) used for data from Ecowitt sensors and can/could be repurposed, the wview_extended database schema is hopelessly too small to accommodate all existing Ecowitt sensors in their maximum number per console. (see Sensor max number). In its maximum implementation 44 sensors need to be accommodated in the database (March 2024). So when the repurposing didn't work anymore, users needed to add new fields to the database based on need.

We will provide here further down a “wview_ecowitt” database schema and, for users of the Interceptor driver, a modified Interceptor driver and the related definitions for related units like °C, °F, %, V, km/h, mph etc.)

in the effort to complete the http-Ecowitt-Gateway driver the creation of a new “wview_ecowitt” database schema to be provided as a choice with the weewx installation package is under discussion - the here so far proposed schema will be adapted once the new schema is completed and accepted by the developer group

—————————————————————————————————————————————————————————

how does weewx work
weewx has three main configuration files which can also be edited by the user:

the weewx core application receives data from its driver (defined in weewx.conf) in a polling interval (e.g. 1 second) and puts this data into two tables (Python dictionaries), the loop table and the archive table. There is a default accumulator definition which tells how the data received from the driver is handled (= what is written into the loop and archive tables), the average, minimum, maximum, summary etc. of the data received during one archiving interval (default 300 seconds = 5 minutes). The archive table corresponds exactly to the database schema, i.e. everything in the archive table will be written (saved, archived) to the weewx database. The loop table can contain more data for which no database field exists. This data can still be shown in the next report (webpage) as current data together with archived data.

After the data is archived the reporting cycle starts and reports defined and activated in weewx.conf will be created by the generator services (e.g. image generator, report generator, history generator to name a few). The results (pictures and webpages) will be written to a report directory (defined in weewx.conf) where the webserver can display them as a webpage.

weewx supports sqlite and mySQL databases (to be selected/defined in weewx.conf)

Meanwhile the loop cycle starts again while the report(s) is (are) generated.

The webserver is not a computer, not a server in the web/internet, but a program or service which can display html pages as web pages (or run php scripts together with a php service and display web pages). What you see when you enter http: (or https:) and then an IP address or domain is what the webserver program on the hosting server shows you as an answer to your request.

—————————————————————————————————————————————————————————

where are the main weewx files located in the file system
the below table is for the Debian type of installation

*) here not with the weewx installation coming drivers and extensions are located - default weewx drivers are in /usr/share/weewx/weewx/drivers
**) default value - in our proposed setup there is a symbolic link to /var/weewx/reports installed where the files will be found

——————————————————————————————————————————————————————————————————-

based on local Ecowitt driver version 0.6.3 - no WS85 signal and battery support yet

wind and piezo rain data are the same as with the WS90 - so they do arrive
with driver version 0.6.1 the WH46 sensor is not yet supported - see local Ecowitt API

with driver version 0.6.3 the WH46 and WS85 sensors are supported for their observations but the WS85 not yet for its signal and battery values - the LDS01 sensor is NOT yet supported

driver download from:
local binary API driver a.k.a. GW1000 driver

for consoles and gateways with the local http API (link) a new EcowittHttp driver (see introduction and overview (link) and the new EcowittHttp driver (link)

People using 0.6.3 with a WH45 will have to rename pm10 and pm10_24h_avg to pm10_0 and pm10:0_24h_avg in their filed_map/field_map_extension or assignment in the [StdCalibrate] stanza (or rename the respective database fields)

in alphabetical order

Notes:

  1. Supported by the API but not yet supported by WSView Plus app or a sensor.
  2. API supports 16 soil moisture sensors but WSView Plus app appears to support only eight soil moisture sensors.
  (this will change from GW2000 firmware 3.1.5 on - the extension for 16 soil moisture sensors will be rolled out 
  step-by-step for all IoT-enabled consoles plus GW1100 and the HP2x0 consoles)
  3. 0.7.0 should also support the LDS01 Laser Distance sensors (1-4) with their observations, air, depth, thi [total height], ldsbatt and ldsheat [inbuilt lens heater switch on/off count])

If you don't have a database schema which contains all possible Ecowitt fields to store your sensor data, you have several possibilities to store readings/observation not available in the default wview_extended database schema

1. re-purpose unused fields already available in the wview_extended database schema
for this you either make the field assignment in the [StdCalculate] [[Corrections]] stanza in weewx.conf


1.a example for the GW1000 driver and the WS90 piezo rain data re-purposing the hail and hailRate database fields of the wview_extended database schema which are not used by Ecowitt console data:

[StdCalibrate]
    
    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2
        luminosity = radiation * 126.7   #if you use the local Ecowitt API then remove the #
                                           # the Interceptor driver doesn't need this line
        hail = p_rain if p_rain is not None else None
        hailRate = p_hailRate if p_hailRate is not None else None
        

1.b example for the Interceptor driver and the WS90 piezo rain data re-purposing the hail and hailRate database fields of the wview_extended database schema which are not used by Ecowitt console data:

( the new ecowittcustom driver has already all needed data fields posted by the Cumusomized server of the console implemented in its internal field map - so no extra field-map or field-map-extension should be needed. The same applies to the assignment of observations to units/unit groups; a complete extensions.py file with the needed definitions is provided.
Also a new Ecowitt database base schema is provided)
⇒ the below description which refers to the old interceptor driver does no longer apply !
It will be removed from the WiKi in due time

[StdCalibrate]
    
    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2
        # luminosity = radiation * 126.7   #if you use the local Ecowitt API then remove the #
                                           # the Interceptor driver doesn't need this line
        hail = rain_piezo if rain_piezo is not None else None
        hailRate = rrain_piezo if rrain_piezo is not None else None
        hailBatteryStatus = ws90cap_volt if ws90cap_volt is not None else None

for this to work the driver interceptor.py must contain the following entries in the DEFAULT_SENSOR_MAP = {} definition - if it doesn't, add them

  DEFAULT_SENSOR_MAP = {
         ......
        'rain_piezo': 'rain_piezo',
        'rrain_piezo': 'rrain_piezo',
        'erain_piezo': 'erain_piezo',
        'hrain_piezo': 'hrain_piezo',
        'drain_piezo': 'drain_piezo',
        'wrain_piezo': 'wrain_piezo',
        'mrain_piezo': 'mrain_piezo',
        'yrain_piezo': 'yrain_piezo',
        'ws90cap_volt': 'ws90cap_volt',
        'ws85cap_volt': 'ws85cap_volt',
        'ws90_ver': 'ws90_ver',
        'ws85_ver': 'ws85_ver',
        'runtime': 'runtime',
        'ws_interval': 'interval',
        'model': 'model',
        'stationtype': 'stationtype',
        'gain0': 'gain0',
        'gain1': 'gain1',
        'gain2': 'gain2',
        'gain3': 'gain3',
        'gain4': 'gain4',
        'gain5': 'gain5',
        'gain6': 'gain6',
        'gain7': 'gain7',
        'gain8': 'gain8',
        'gain9': 'gain9',
        .......
        }

alternatively, without modifying the source code of interceptor.py and without assignments in the [StdCalibrate] [[Corrections]] stanza, one can add a field_map_extension inside the [Interceptor] or [GW1000] stanza, depending on which driver one uses
example

[[field_map_extensions]]
    weewx_field_name = ecowitt_field_name
    ......
    
    # concrete example
    
        hail = rain_piezo
    hailRate = rrate_piezo

or
create a [[field-map-extensions]] in your [GW1000] or [Interceptor] stanza in weewx.conf with the respective assignment(s)

2. create new database fields and assign the observations via [field-map-extentions]

in all cases make sure the following entries have been added to the extensions.py file which is located in the same directory as the user driver files e.g. gw1000.py, interceptor.py

weewx.units.obs_group_dict['hailRate'] = 'group_rainrate'
weewx.units.obs_group_dict['hail'] = 'group_rain'

—————————————————————————————————————————————————————————

this section is still work in progress !!

the EcowittHttp driver as it is available (test version* !) right now (July 2025) does a mandatory backfill of data from either a SD card (GW3000, WS6210) or from the Ecowitt cloud (ecowitt.net). The SD card data backfill supersedes the cloud backfill (weewx lingo: “catchup”).
If not all three parameters (APP key, API key, MAC address of console in question) are provided in weewx.conf, the ecowitt.net backfill/catchup fails.

A so-far undocumented option in the [StdArchive] stanza activates the backfilling/catchup
Thanks to @Tom Keffer for pointing that out !

[StdArchive]
    
    # If the station hardware supports data logging then the archive interval
    # will be downloaded from the station. Otherwise, specify it (in seconds).
    archive_interval = 300
    
    # catchup at startup option    
    no_catchup = 0    #: 0 or not set: catchup takes place, 1: no catchup takes place

*) due to an unforeseen limited availability of the original author and developer of the EcowittHttp driver,
a team of Ecowitt experts and programmers has taken on the final tests and completion of the already 99.9 % readily programmed driver to make it available to the weewx community

proposed entries for weewx.conf stanzas

[station]
# Description of the station location
    location = "your location"
    
    # Latitude in decimal degrees. Negative for southern hemisphere
    latitude = 49.2673  # example - put your latitude
    # Longitude in decimal degrees. Negative for western hemisphere.
    longitude = 7.0325  # example - put your longitude
    
    # Altitude of the station, with unit it is in. This is downloaded from
    # from the station if the hardware supports it.
    altitude = 287, meter   # example - put your altitude
    
    # The start of the rain year (1=January; 10=October, etc.). This is
    # downloaded from the station if the hardware supports it.
    rain_year_start = 1
    
    # Start of week (0=Monday, 6=Sunday)
    week_start = 6
    # your weather station
    station_type = EcowittHttp
##############################################################################
    
[EcowittHttp]
    # This section is for the Ecowitt local HTTP API driver.
    
    # the driver to use
    driver = user.ecowitt_http
    
    # how often to poll the device - number of seconds
    poll_interval = 8
    # how many attempts to contact the device before giving up
    max_tries = 3
    # wait time in seconds between retries to contact the device
    retry_wait = 2
    # max wait for device to respond to a HTTP request - number of seconds
    url_timeout = 3
    
    # whether to show all battery state data including nonsense data and 
    # sensors that are disabled sensors and connecting
    show_all_batt = False
    # whether to ignore battery state data from legacy WH40 sensors that do 
    # not provide valid battery state data
    ignore_legacy_wh40_battery = True
    # whether to always log unknown API fields, unknown fields are always 
    # logged at the debug level, this will log them at the info level
    log_unknown_fields = False
    
    # How often to check for device firmware updates, 0 disables firmware 
    # update checks. Available firmware updates are logged.
    firmware_update_check_interval = 86400
    
    # provide additional log information to help debug rainfall issues
    debug_rain = False
    # provide additional log information to help debug wind issues
    debug_wind = False
    # provide additional log information to help debug loop packet issues
    debug_loop = False
    # provide additional log information to help debug sensor issues
    debug_sensors = False
    ip_address = 192.168.1.100   # example !! - replace by the IP address of your console/gateway
    # provide Ecowitt API and APP key to have permission for the ecowitt.net backfill download
       # api_key = xxxxxxxxxxxxxxx
       # app_key = xxxxxxxxxxxxxxx
    # MAC address to identify the console
       # mac = xx:xx:xx:xx:xx:xx
    # if the device (IP address) is a device with a SD card, the backfill from the SD card is initiated at startup
    # if not SD card device is available, the backfill (weewx lingo: "catchup") from ecowitt.net will be initiated
    # start time = last weewx database archiving record timestamp
    [[field_map_extensions]]
        batteryStatus1 = ws90.battery
        rain = rain.0x10.val
        stormRain = rain.0x0D.val
        rainRate = rain.0x0E.val
        hourRain = t_rainhour
        dayRain = rain.0x10.val
        weekRain = rain.0x11.val
        monthRain = rain.0x12.val
        yearRain = rain.0x13.val
        is_raining = piezoRain.srain_piezo.val
        p_rain = piezoRain.0x10.val
        p_stormRain = piezoRain.0x0D.val
        p_rainRate = piezoRain.0x0E.val
        p_hourRain = p_rainhour
        p_dayRain = piezoRain.0x10.val
        p_weekRain = piezoRain.0x11.val
        p_monthRain = piezoRain.0x12.val
        p_yearRain = piezoRain.0x13.val
        vpd = common_list.5.val
        lightning_distance = lightning.distance
        lightning_last_det_time = lightning.timestamp
        lightningcount = lightning.count
        pm2_5 = ch_pm25.1.PM25_RealAQI
        pm2_52_24h_avg = ch_pm25.1.PM25_24HAQI
        pm10_0 = co2.PM10
        luminosity = common_list.0x15.val

##############################################################################

#   This section can adjust data using calibration expressions.

[StdCalibrate]
    
    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        radiation = luminosity/126.7 if luminosity is not None else None
        luminosity = 0 if luminosity == None else luminosity
        UV = UV * 0.8272727272727273     # here a value of 0.65 has shown suitable
                                         # if you apply a gain factor of 0.65 or any other of your choice 
                                         # already in the console/gateway calibration, this line is not needed !!
                                         # Ecowitt might change in future their UVI calculation
                                         # today (July 2025) it is the rounded integer of radiation / 100
        lightningcount = lightningcount if lightningcount > 0 else 0
        lightning_strike_count = lightningcount
        lightning_distance = None if lightning_strike_count == 0 else lightning_distance
        stormRain = 0 if stormRain == None else stormRain
        p_stormRain = 0 if p_stormRain == None else p_stormRain
        isRaining = is_raining

##############################################################################

#   This section controls the origin of derived values.

[StdWXCalculate]
    
    [[Calculations]]
        # How to calculate derived quantities.  Possible values are:
        #  hardware        - use the value provided by hardware
        #  software        - use the value calculated by weewx
        #  prefer_hardware - use value provide by hardware if available,
        #                      otherwise use value calculated by weewx
        
        pressure = prefer_hardware
        vpd = prefer_hardware
        AirDensity = software
        altimeter = prefer_hardware
        appTemp = prefer_hardware
        barometer = prefer_hardware
        cloudbase = prefer_hardware
        dewpoint = prefer_hardware
        ET = software
        heatindex = prefer_hardware
        humidex = prefer_hardware
        inDewpoint = prefer_hardware
        maxSolarRad = prefer_hardware
        rainRate = prefer_hardware
        p_rainRate = prefer_hardware
        dayRain = prefer_hardware
        p_dayRain = prefer_hardware
        weekRain = prefer_hardware
        p_weekRain = prefer_hardware
        monthRain = prefer_hardware
        p_monthRain = prefer_hardware
        yearRain = prefer_hardware
        p_yearRain = prefer_hardware
        stormRain = prefer_hardware
        p_stormRain = prefer_hardware
        windchill = prefer_hardware
        windrun = software
        beaufort = prefer_hardware
        abs_humidity = prefer_hardware, archive
        p_rain = prefer_hardware
        lightning_strike_count = prefer_hardware
        rain = prefer_hardware
    [[WXXTypes]]
        
        [[[ET]]]
            
            wind_height = 5.0
    [[Delta]]
        [[[rain]]]
            input = t_rainyear
        [[[p_rain]]]
            input = p_rainyear
        [[[lightning_strike_count]]]
            input = lightningcount
        [[[lightning_distance]]]
            input = lightning_distance

##############################################################################

[StdArchive]
    
    # If the station hardware supports data logging then the archive interval
    # will be downloaded from the station. Otherwise, specify it (in seconds).
    archive_interval = 300
    
    # catchup at startup option    
    no_catchup = 0    #: 0 or not set: catchup takes place, 1: no catchup takes place
    
    # If possible, new archive records are downloaded from the station
    # hardware. If the hardware does not support this, then new archive
    # records will be generated in software.
    # Set the following to "software" to force software record generation.
    # record_generation = hardware
    record_generation = software
    
    # Whether to include LOOP data in hi/low statistics
    loop_hilo = True
    
    # The data binding used to save archive records
    data_binding = wx_binding

—————————————————————————————————————————————————————————

the GW2000 and GW3000 consoles also provide an option to use MQTT protocol with the customized server string (Ecowitt protocol) as payload

an example for a respective [MQTTSubscribeDriver] stanza below

[MQTTSubscribeDriver]
    driver = user.MQTTSubscribe
    host = broker.mqtt.cool
    port = 1883
    keepalive = 60
    username = None
    password = None
    binding = loop
    
    [[topics]]
        unit_system = US
        [[[ecowitt/1C6920E3A8F3]]]
           subscribe = True
           ignore = False
            [[[[message]]]]
                type = keyword
                keyword_delimiter = "&"
            [[[[PASSKEY]]]]
                ignore = True
            [[[[stationtype]]]]
                ignore = True
            [[[[runtime]]]]
                ignore = True
            [[[[dns_err_cnt]]]]
                ignore = True
            [[[[cdnflg]]]]
                ignore = True
            [[[[dateutc]]]]
                ignore = True
            [[[[freq]]]]
                ignore = True
            [[[[model]]]]
                ignore = True
            [[[[baromrelin]]]]
                name = barometer
            [[[[baromabsin]]]]
                name = pressure
            [[[[dailyrainin]]]]
                name = dayRain
            [[[[drain_piezo]]]]
                name = p_dayRain
            [[[[erain_piezo]]]]
                name = p_stormRain
            [[[[eventrainin]]]]
                name = stormRain
            [[[[hourlyrainin]]]]
                name = hourRain
            [[[[hrain_piezo]]]]
                name = p_hourRain
            [[[[humidityin]]]]
                name = inHumidity
            [[[[humidity]]]]
                name = outHumidity
            [[[[last24hrain_piezo]]]]
                name = p_24Rain
            [[[[last24hrainin]]]]
                name = 24Rain
            [[[[lightning]]]]
                name = lightning_dist
            [[[[lightning_num]]]]
                name = lightning_strike_count
            [[[[lightning_time]]]]
                name = lightning_last_det_time
            [[[[monthlyrainin]]]]
                name = monthRain
            [[[[mrain_piezo]]]]
                name = p_monthRain
            [[[[rainratein]]]]
                name = rainRate
            [[[[rrain_piezo]]]]
                name = p_rainRate
            [[[[solarradiation]]]]
               name = radiation
            [[[[srain_piezo]]]]
                name = isRaining
            [[[[tempf]]]]
                name = outTemp
            [[[[tempinf]]]]
               name = inTemp
            [[[[uv]]]]
                name = UV
            [[[[weeklyrainin]]]]
                name = weekRain
            [[[[wrain_piezo]]]]
                name = p_weekRain
            [[[[winddir]]]]
                name = windDir
            [[[[windgustmph]]]]
                name = windGust
            [[[[windspeedmph]]]]
               name = windSpeed
            [[[[yearlyrainin]]]]
                name = yearRain
            [[[[yrain_piezo]]]]
                name = p_yearRain

##############################################################################

—————————————————————————————————————————————————————————

what do you see on your local or internet webpage

we will now use the weewx default skin (Seasons skin) to demonstrate the results created by weewx (pictures below). What is shown first is the current data and the current day history plus min/max history so far.
weewkly, monthly and yearly views are also available - selection on top menu (History)

The skin (web page) is divided into several sections:

1. the current data table top left (left portion of the page) - red circle
2. the celestial data table (if activated in skin.conf) - top of blue circle
3. the min/max data of the chosen time frame for each observation (sensor data) - blue circle
4. the history of the chosen time frame (default current day) as graphs/pictures

There are many other skins available at your liking which can also be produced in parallel e.g. neowx material, wdc (Weather Data Center) and many more. There's also the Belchertown skin with realtime data which however needs a more complex setup. We will dedicate an extra section to this solution.



what if air pressure and/or solar radiation are not shown on your page ??

there are a few “oddities” in how weewx handles observations (information/data related to a sensor reading).

One is solar radiation information provided by Ecowitt consoles. What Ecowitt consoles provide is in the strict sense not solar radiation (that would need a pyranometer to provide data) but light. The technical term is luminosity. And weewx distincts between radiation and luminosity. Luminosity, however, is not used in the standard setup for displaying observations. What is used is (solar) radiation. But radiation is not archived nor available to display. What to do ? We have to assign the luminosity information which is provided by the consoles to the radiation field in the database. And as luminosity is provided as a photometric entity measured in Lux units, it needs to be converted into a radiometric energy entity measured in W/m² units.
In order to do so we have to enter a “correction” in the weewx.conf configuration file: we assign luminosity to radiation and perform a value conversion. (It's a value conversion - the units cannot be converted into each other - we rather provide a correspondance).

the weewx configuration files (weewx.conf, skin.conf etc.) are segmented into different (hierarchical) sections named stanzas

• level 1: [ ………]
• level 2: [[ ........]]
• level 3: [[[ .......]]] etc.

(e.g. your station definition is a level one stanza e.g. [GW1000] or [Interceptor])
there is a section/stanza in weewx.conf which deal with (configurable] calculations to be performed by weewx
[StdCalculate] with a subsection
[[Corrections]] where corrections, calibrations, (re-)assignments of variables etc. can be made
here we have to enter the line (Python code)
radiation = luminosity / 126.7 if luminosity is not None else None

# ......
# *********************
[Station]
 station_type = GW1000 
# *********************
#......
# *********************
[GW1000]
# ....
driver = user.gw1000
    ip_address = 192.168.1.xxx
    poll_interval = 10       # you can also choose longer or shorter polling intervals
                             # if you own a WS80 array, you may want to choose 5 seconds
                             # if you use the Belcherstown skin, you may want to choose 4 or 5 seconds with a WS80
# *********************
# ....
# *********************
[StdCalculate]
# .......
[[Corrections]]

radiation = luminosity / 126.7 if luminosity is not None else None 
# .........
# *********************

luminosity versus radiation - Lux versus W/m²
where the number 126.7 comes from is a longer story which needs some background information and understanding of physics. We will explain below as the explanation is difficult to find.
see also: http://hyperphysics.phy-astr.gsu.edu/hbase/vision/bright.html
important things to understand:

1. measuring light intensity is a photometric activity - measuring radiation and resulting wattage is a radiometric activity
2. photometric units cannot be directly converted into radiometric units - therefore, a correspondence between the measurands (specific quantity, property, or object that is intended to be measured) needs to be established

• The peak of the luminosity function is at 555 nm (green); the eye’s visual system is more sensitive to light of this wavelength than any other. For monochromatic light of this wavelength, the irradiance needed to make one Lux is minimum, at 1.464 mW/m².
• That is, one obtains 683.002 lux per W/m² (or lumens per watt) at this wavelength. Other wavelengths of visible light produce fewer lumens per watt.
• Solar Radiation is a shorter wave length and different color spectrum, so it has a different factor of Lux to W/m2:
• Bright sunlight is approximately 136,000 lux ~ 1,075 W/m² ⇒ 136,000 / 1,075 = 126.7
• The factor changes slightly depending on time of day, conditions such as cloud cover, moisture in the air etc. and most sources agree on the 126.7 as a reasonable factor to use.
• The conversion in the green visible light spectrum spectrum at 555nm is 1W/m² = 683 lux, and is used of human eyes.

NOTE: here, the anglo-saxon notations of comma and point are used: the comma (“,”) separates groups of one thousands before the decimal point (“.”) - whereas in central European notation the inverse is the case (a “.” is used for separation of groups of thousands and the decimal point is a comma (“,”)).

this correction is only needed for the Ecowitt Gateway (GW1000) driver - NOT for the interceptor driver
(there the observations arrive already as radiation)

For the Interceptor driver the entries in weewx.conf should look like this

#############################################################################

[Interceptor]
    # This section is for the network traffic interceptor driver.
    
    # The driver to use:
    driver = user.interceptor
    
    # Specify the hardware device to capture.  Options include:
    #   acurite-bridge - acurite internet bridge, smarthub, or access
    #   observer - fine offset WH2600/HP1000/HP1003, ambient WS2902
    #   lw30x - oregon scientific LW301/LW302
    #   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge
    #   ecowitt-client - any hardware that uses the ecowitt protocol
    #   wu-client - any hardware that uses the weather underground protocol
    #    device_type = fineoffset-bridge
    device_type = ecowitt-client
    port = 8000   # this port number has to match the port in the customized server section
                  # do not use port 80 or 443 as they are reserved for standard web access
    address = 192.168.1.39 # this is an example - here comes the IP of your RaspberryPi or NAS server or VM
    iface = wlan0  # or eth0 when you are using the LAN (Ethernet) interface of your server

##############################################################################

The custom server entries in your console should be:

The other “oddity” is air pressure.

There are three observations related to pressure. Some stations report only the station pressure, others calculate and report sea level pressures.

*) the proper scientific term would be rather “normalized”

Now there are two things:
1. Ecowitt consoles provide station pressure or absolute pressure
2. when displaying barometer, weewx has to be able to calculate Sea Level Pressure from the absolute pressure and (!) the average* local temperature during the past 12 hours (!) ⇒ weewx can only provide a barometer value once weewx has been running and collecting and archiving data for 12 and more hours.

* however, the “average” temperature here is NOT the average temperature over the past 12 hours

sum[T₁ + T₂ + …+ T_x] / x for x = 144 or 144 5 minute intervals = 12 hours,
but just
(T_now - T_12-h-ago) / 2

the background for using also the local temperature for air pressure correction is this:

• air pressure is created by the mass of air above a location (air column ~11 km high)
• temperature is defined by the movement of the air particles
• the vertical component of air movement creates a force on a certain area - the definition of pressure is force / area (p = F/A)
• for the pressure to be equally distributed the air molecules have to come to a full mixing by diffusion - therefore the 12 h average temperature is used to calculated the real air pressure

from where weewx takes its pressure data is determined by the following entries in weewx.conf

[StdWXCalculate]
    
    [[Calculations]]
        # How to calculate derived quantities.  Possible values are:
        #  hardware        - use the value provided by hardware
        #  software        - use the value calculated by weewx
        #  prefer_hardware - use value provide by hardware if available,
        #                      otherwise use value calculated by weewx
        
        pressure = prefer_hardware
        altimeter = prefer_hardware
        barometer = prefer_hardware

if you want to use the new dynamic sea level pressure feature of the modern Ecowitt consoles/gateways and display it in your skin via the “barometer” variable, you'd have to assign in weewx.conf

[StdCalibrate]
    
    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2
        barometer = relbarometer

if you want weewx to calculate it from the absolute pressure your console provides, the entry in
[StdWXCalculate]
[[Calculations]]
would have to be
barometer = software

for more air pressure related information see Barometer

————————————————————————————————————————————————————————————————-

how to show the Seasons skin on your web host

what web pages (skins) will be created is defined in weewx.conf in the [StdReport] stanza. The files needed for the web pages to display properly will be written into the directory mentioned under HTML_ROOT. HTML_ROOT (or web root) is the directory on your local or internet server where the webserver (program !) on this server reads and then publishes (displays) the web pages. For a weewx skin this will be html files and pictures. The services Cheetah-generator and Image-generator create these files based on the definitions in skin.conf and index.html.tmpl by reading the needed data from the weewx database (and the current data from the loop table). As weewx rather rarely runs on an internet hosted server, this will be a local server (e.g. a RaspberryPi, a NAS server or another local server with Linux OS.

To get the files to your internet server the [[FTP]] “skin” is used. It is not a real skin, but under this stanza all the information for a ftp client to send data to your internet server has to be put.
the files (html, pictures) have to be transferred to the directory on your internet server where the webserver service can pick them up, when it receives a display request. The display request is created when you enter a URI/URL in your browser: e.g. https://my-domain.net/weewx. When the webserver receives this request, it looks into its web directory (web root) and checks if a file named index.html is found. If yes, it executes the instructions it finds in this file. When the weewx created file index.html is found, the respective skin (here Seasons) will be displayed (provided the file transfer was complete and all needed html and picture files are available).

On the server (local or internet) there is usually the directory /var/www/html or /var/www/public_html used for this. However, unless you have root permissions on that server (which for internet servers is rather rare), your ftp client will end up at the web root directory. In your control panel you will be told what path you have to enter in your ftp client resp. in the [[FTP]] stanza. It is advisable to create subdirectories under your web root for different web sites you may have. For example the directory weewx for your weewx website.

when you fill in the proper information in the [[FTP]] stanza (example below), weewx will send the web pages via ftp to your website, after these files have been created locally by the Cheetah- and Imagegenerator in the archiving and reporting cycle. (provided your local server has internet access).

the locations where weewx puts central information are different depending on the weewx installation method you choose/chose and the weewx version.

REMARK: in the below example HTML_ROOT = /var/weewx/reports only works because a symbolic link from /var/www/html/weewx to /var/weewx/reports has been set. Another (not recommended) possibility would be to define /var/weewx/report as the webserver directory.

In another chapter below we will give an example for a weewx setup on a RaspberryPi or NAS server where this symbolic link will be used (and its purpose explained)

[StdReport]
    
    # Where the skins reside, relative to WEEWX_ROOT
    SKIN_ROOT = /etc/weewx/skins
    
    # Where the generated reports should go, relative to WEEWX_ROOT
    HTML_ROOT = /var/weewx/reports
    
    # The database binding indicates which data should be used in reports.
    data_binding = wx_binding
    
    # Whether to log a successful operation
    log_success = True
    
    # Whether to log an unsuccessful operation
    log_failure = True
    
    # Each of the following subsections defines a report that will be run.
    # See the customizing guide to change the units, plot types and line
    # colors, modify the fonts, display additional sensor data, and other
    # customizations. Many of those changes can be made here by overriding
    # parameters, or by modifying templates within the skin itself.

    [[SeasonsReport]]
        # The SeasonsReport uses the 'Seasons' skin, which contains the
        # images, templates and plots for the report.
        skin = Seasons
        enable = true
# ......................
    [[FTP]]
        # FTP'ing the results to a webserver is treated as just another report,
        # albeit one with an unusual report generator!
        skin = Ftp
        
        # If you wish to use FTP, set "enable" to "true", then
        # fill out the next four lines.
        # Use quotes around passwords to guard against parsing errors.
        enable = true
        user = username
        password = your-password
        server = your domain.com    # The ftp server name, e.g, www.myserver.org
        path = /www/weewx    # The destination directory, e.g., /weather
        
        # Set to True for an FTP over TLS (FTPS) connection. Not all servers
        # support this.
        secure_ftp = False
        
        # To upload files from something other than what HTML_ROOT is set
        # to above, specify a different HTML_ROOT here.
        #HTML_ROOT = /var/weewx/reports
        
        # Most FTP servers use port 21
        port = 21
        
        # Set to 1 to use passive mode, zero for active mode
        passive = 1

———————————————————————————————————————————————————————————

how to install weewx on a RaspberryPi or NAS server
Prerequites - there is a long discussion about the quality of SD cards used with data logger programs. Most SD cards will not survive frequent database write access operations for a long time. As a result data will get/be lost. There is no compassion with someone who wanted to save at the wrong end or wanted to know it better.
The best policy is to reduce frequent write access to the SD card and have high quality SD card. Best is an industrial SLC card - 32 GB ~ 30 USD/EUR. If you manage to get your RaspberryPi (3B or 4B recommended) booting from a SSD, you are anyway on the safe side.
The setup described below works and avoids many write operations by regular the report generation by using a temporary file system (a RAM disk).

1. install a Linux derivate operating system on your RaspberryPi (e.g. Debian, Raspbian, Ubuntu, …); make sure you use a recent version which already contains Python3 (even though the old Python2 also works, but it's not future oriented. For the RaspberryPi there is the “Raspberry Pi Imager” with which you can copy the OS (operating system) image on an SD card. https://www.raspberrypi.com/software/

2. make sure your system is on the latest version

sudo apt-get update
sudo apt-get upgrade

3. install a webserver program - nginx or apache2 - it is needed for your reports (skins, webpages) to be displayed -

sudo apt-get install apache2

4. install weewx - see http://weewx.com/docs/5.0/
enter your basic data - Name, place, longitude, latitude, altitude (=elevation plus height of your console above ground) - for elevation use e.g. https://www.randymajors.org/elevation-on-google-maps
Choose “Simulator” as station first and get weewx running with it.

5. create the RAM disk for the reports - weewx writes as default every 5 minutes/300 seconds a report with current data etc. - see above - the default place for webpages and related pictures to be stored in a Debian, Raspbian, Ubuntu environment is /var/www/html - there we will create a subdirectory “weewx” so you can later on view your reports by entering the IP-address of your RPi: http://IP-address-of-RPi/weewx. During the installation weewx may already have created this subdirectory - in this case you will get an error message telling that the directory exists already - if so, no problem. we will do now a few things

1. create the subdirectory for the webserver
2. allow the webserver to access this subdirectory
3. create a subdirectory for the report files
4. mount a temperory file system into that link
5. make the mount permanent
6. create a symbolic link that refers to that subdirectory when the /var/www/html/weewx directory is addressed

# 1.
sudo mkdir /var/www/html/weewx
# 2.
sudo chmod -R 755 /var/www/html/weewx
# 3. 
sudo mkdir -p /var/weewx/reports
# 4.
sudo mount -a
# 5.
sudo echo "weewx_reports /var/weewx/reports tmpfs size=20M,noexec,nosuid,nodev 0 0" | sudo tee -a /etc/fstab
# 6. 
sudo ln -s /var/weewx/reports /var/www/html/weewx

further installation instructions come with the driver installation(interceptor or GW1000)
For further configuration details (weewx.conf, GW1000 driver or customized server entries in your console) see Custom Server

getting weewx on your computer and get it installed

how to install weewx on a Windows 10/11 computer (WSL)

if WSL, the Windows Subsystem for Linux, is not (yet) installed on your Windows 10/11 server (PC, laptop, …), you will first have to do this.
steps:

1. activate the WSL Windows Feature
   • press WIN + R keys on the keyboard ⇒ a window opens into which you enter “control” (without “”) and press ENTER
   • on the displayed page you may have to select the detailed view (small symbols, icons)
   • select and click on “Programs and Features” and you will see a window with all applications installed
   • on the left hand side there is an option “activate or deactivate Windows features” - click on it
   • a selection box opens - page down to “Windows Subsystem for Linux” and tag the option
   • a reboot will be needed
   • after the reboot (or WSL already activated) go to 2.
2. open an elevated console windows (=with admin rights) and enter: wsl –install
   (attention: these are two minus signs in front of “install” - no gap!)
   this will install the Linux Ubuntu distribution on your computer inside a virtual machine into which all your Windows drives will be mounted i.e. will be accessible under
   /mnt/x (x= c, d, e … - your Windows drives [HDD, SSD, etc.]
3. you will be asked to enter your user name and password
   (this user does not have root (admin) rights, to execute commands which need root rights, the command will have to be preceded by “sudo” !)
4. the Ubuntu Linux installation will become visible in your Windows File Explorer.
   BEWARE: changes made to files in the Ubuntu file system from within Windows (that's possible and may be more comfortable) should only be made with a text-only editor like Notepad or Notepad++. Otherwise you risk to corrupt the files.

We suggest to pin the WSL console window to your taskbar and keep in open all the time (= do not terminate/close the console window - you can of course minimise it)
closing the window (terminal, console) will put WSL to sleep (Hibernation mode) and may need a renewal of port forwarding and firewall rules (see later). Otherwise weewx can no longer be reached from the network,

installing weewx 5.0 on Ubuntu

a few packages will need to be installed for weewx to work and for getting the needed information

sudo apt install net-tools    # network tools
sudo apt install apache2      # an http/php webserver program to run as a service - to display webpages
                              # common options are nginx and apache2 - we take apache2 here

to be completed

—————————————————————————————————————————————————————————

how to install weewx 5.0 in a Python VENV environment

to be completed

—————————————————————————————————————————————————————————

the Belchertown skin and real-time data display
the Belchertown skin has become famous amongst weewx users as it can be used to (also) display realtime data - as much realtime as the driver for the weather station provides data. It can also be used as a normal skin.

The usual skins coming with weewx or having been developed for weewx do not show realtime data.
They only show data which has been stored in the selected archiving cycle (default: 300 seconds or 5 minutes).
Depending on the hardware on which weewx runs and the amount of work the Cheetah- and Imagegenertors have to do after the archiving (you may have weewx produce many skins and have many sensors), the interval between storing data in the database can only be shortened to a certain extent. Otherwise, the reporting tasks will not have completed once the next archiving occurs and you won't see the recent data on your skin (page) as it was skipped.

The idea which became popular together with the Belchertown skin was to separate the display of realtime/current data from the archiving and the display of historical data. In order to make this happen the MQTT (Message Queuing Telemetry Transport) protocol was used to provide for the realtime data while weewx would save historical data and produce the historical reports in the background.

A MQTT architecture looks like shown below
an information broker (computer program) using the MQTT protocol runs on a server and receives and sends information based on subscription
(source: mqtt.org)

for the Belcherton skin approach such a MQTT broker will be used to receive the weather data from the console and to the server where you web page (Belchertown) and weewx are running.

In MQTT terms weewx, via the Belchertown skin, subscribes to the topic “weather”. The weewx extension weewx-mqtt (has to be installed beforehand) posts the weather data the archive and loop tables are filled with after every update from the GW1000 or Interceptor driver to the MQTT broker (server) as a weather topic. The same weewx having subscribed to the weather topic now receives these messages and the Belchertown skin is updated with realtime data.

The update interval is defined by the polling interval of the GW1000 driver resp. by the posting interval of the console to weewx (custom server –> Interceptor driver).

data flow: sensors –> console –> weewx driver –> loop/archive table –> MQTT broker –> subscribers (weewx Belchertown skin)

for this to work not only the Belchertwon skin needs to be installed but also the weewx-MQTT extension to post the data the loop/archive table receives from the driver to the MQTT broker. You may need to install a MQTT broker (service) on a separate server (RaspberryPi, NAS) for the data sent from weewx to be received and posted to the Belchertown skin (which has subscribed to the topic). Details see link below. For this mostly the mosquito MQTT service is used. Running the MQTT service (mosquito) on the same server [VM] where weewx is running on is not recommended as it can create a lot of issues.

below an example of the Belchertown skin home page (dark mode - bright mode also available)


want to install the skin ? see
installing the weewx Belchertown skin

—————————————————————————————————————————————————————————————

While the Davis Vantage VP2 based wview_extended database schema contains 103 fields, the proposed wview_ecowitt database schema contain 253 entries covering all possible Ecowitt sensors and their related data (readings, battery status and signal status).
Also here certain environment related sensors have been taken on from the wview_extended database schema like CO, NO2, noise, NH3.

The wview_ecowitt database schema is oriented at the http string the customized server posting sends. It also contains observations which are not contained in the local Ecowitt Gareway API response. As Ecowitt have decided not to further develop the local tcp/ip API (telnet), the full range of sensors can only be retrieved and archived based on the (extended) interceptor driver.
(Or by using a driver which is using the http API resp. extending e.g. the existing local Ecowitt Gateway driver by http calls to the http API)

The database schema is used by weewx only once at its first start when no database is present. From there it retrieves the information for size and content of the loop and archive tables. If one already has a weewx database in use for a longer time, there are several ways how to migrate to the new database schema:

• add the missing fields with the weewx wee_database tool or weectl database from weewx version 5.0
• create a new empty database and migrate the data with the wee_database tool or sqlite/mySQL tools (–> weewx documentation convert weewx database)

For the database field names we have taken (with a few exceptions of fields which are not provided by the local Ecowitt gateway driver) the names from the field map in https://github.com/gjr80/weewx-gw1000/wiki/Field-map. They do not always match the names used by the customized server postings which are picked up by the interceptor driver. For the interceptor driver we will then have to match the names from the driver with the weewx names (database field names) by the help of a [[field-map]] or [[field-map-extensions]] definition in weewx.conf in the [Interceptor] stanza. This will be described below in the Interceptor Driver section Interceptor Driver

the proposed wview_ecowitt database schema wview_ecowitt.zip

table = [('dateTime',             'INTEGER NOT NULL UNIQUE PRIMARY KEY'),
         ('usUnits',              'INTEGER NOT NULL'),
         ('interval',             'INTEGER NOT NULL'),
         ('altimeter',            'REAL'),
         ('appTemp',              'REAL'),
         ('appTemp1',             'REAL'),
         ('barometer',            'REAL'),
         ('pressure',             'REAL'),
         ('relbarometer',         'REAL'),
         ('batteryStatus1',       'REAL'),
         ('batteryStatus2',       'REAL'),
         ('batteryStatus3',       'REAL'),
         ('batteryStatus4',       'REAL'),
         ('batteryStatus5',       'REAL'),
         ('batteryStatus6',       'REAL'),
         ('batteryStatus7',       'REAL'),
         ('batteryStatus8',       'REAL'),
         ('cloudbase',            'REAL'),
         ('co',                   'REAL'),
         ('co2',                  'REAL'),
         ('consBatteryVoltage',   'REAL'),
         ('dewpoint',             'REAL'),
         ('dewpoint1',            'REAL'),
         ('ET',                   'REAL'),
         ('extraHumid1',          'REAL'),
         ('extraHumid2',          'REAL'),
         ('extraHumid3',          'REAL'),
         ('extraHumid4',          'REAL'),
         ('extraHumid5',          'REAL'),
         ('extraHumid6',          'REAL'),
         ('extraHumid7',          'REAL'),
         ('extraHumid8',          'REAL'),
         ('extraTemp1',           'REAL'),
         ('extraTemp2',           'REAL'),
         ('extraTemp3',           'REAL'),
         ('extraTemp4',           'REAL'),
         ('extraTemp5',           'REAL'),
         ('extraTemp6',           'REAL'),
         ('extraTemp7',           'REAL'),
         ('extraTemp8',           'REAL'),
         ('wh31_ch1_batt',         'REAL'),
         ('wh31_ch2_batt',         'REAL'),
         ('wh31_ch3_batt',         'REAL'),
         ('wh31_ch3_batt',         'REAL'),
         ('wh31_ch4_batt',         'REAL'),
         ('wh31_ch5_batt',         'REAL'),
         ('wh31_ch6_batt',         'REAL'),
         ('wh31_ch7_batt',         'REAL'),
         ('wh31_ch8_batt',         'REAL'),
         ('wh31_ch1_sig',         'REAL'),
         ('wh31_ch2_sig',         'REAL'),
         ('wh31_ch3_sig',         'REAL'),
         ('wh31_ch3_sig',         'REAL'),
         ('wh31_ch4_sig',         'REAL'),
         ('wh31_ch5_sig',         'REAL'),
         ('wh31_ch6_sig',         'REAL'),
         ('wh31_ch7_sig',         'REAL'),
         ('wh31_ch8_sig',         'REAL'),
         ('forecast',             'REAL'),
         ('hail',                 'REAL'),
         ('hailBatteryStatus',    'REAL'),
         ('hailRate',             'REAL'),
         ('heap_free',             'REAL'),
         ('heatindex',            'REAL'),
         ('heatindex1',           'REAL'),
         ('heatingTemp',          'REAL'),
         ('heatingVoltage',       'REAL'),
         ('humidex',              'REAL'),
         ('humidex1',             'REAL'),
         ('inConsoleBatteryStatus','REAL'),
         ('inDewpoint',           'REAL'),
         ('inHumidity',           'REAL'),
         ('inTemp',               'REAL'),
         ('inTempBatteryStatus',  'REAL'),
         ('leafTemp1',            'REAL'),
         ('leafTemp2',            'REAL'),
         ('leafWet1',             'REAL'),
         ('leafWet2',             'REAL'),
         ('leafWet3',             'REAL'),
         ('leafWet4',             'REAL'),
         ('leafWet5',             'REAL'),
         ('leafWet6',             'REAL'),
         ('leafWet7',             'REAL'),
         ('leafWet8',             'REAL'),
         ('wn35_ch1_batt',         'REAL'),
         ('wn35_ch2_batt',         'REAL'),
         ('wn35_ch3_batt',         'REAL'),
         ('wn35_ch3_batt',         'REAL'),
         ('wn35_ch4_batt',         'REAL'),
         ('wn35_ch5_batt',         'REAL'),
         ('wn35_ch6_batt',         'REAL'),
         ('wn35_ch7_batt',         'REAL'),
         ('wn35_ch8_batt',         'REAL'),
         ('wn35_ch1_sig',         'REAL'),
         ('wn35_ch2_sig',         'REAL'),
         ('wn35_ch3_sig',         'REAL'),
         ('wn35_ch3_sig',         'REAL'),
         ('wn35_ch4_sig',         'REAL'),
         ('wn35_ch5_sig',         'REAL'),
         ('wn35_ch6_sig',         'REAL'),
         ('wn35_ch7_sig',         'REAL'),
         ('wn35_ch8_sig',         'REAL'),
         ('leak1',                'REAL'),
         ('leak2',                'REAL'),
         ('leak3',                'REAL'),
         ('leak4',                'REAL'),
         ('wn55_ch1_batt',        'REAL'),
         ('wn55_ch2_batt',        'REAL'),
         ('wn55_ch3_batt',        'REAL'),
         ('wn55_ch3_batt',        'REAL'),
         ('wn55_ch4_batt',        'REAL'),
         ('wn55_ch1_sig',         'REAL'),
         ('wn55_ch2_sig',         'REAL'),
         ('wn55_ch3_sig',         'REAL'),
         ('wn55_ch3_sig',         'REAL'),
         ('wn55_ch4_sig',         'REAL'),
         ('lightning_distance',      'REAL'),
         ('lightning_last_det_time', 'INTEGER NOT NULL'),
         ('lightning_strike_count',  'REAL'),
         ('lightningcount',          'REAL'),
         ('luminosity',           'REAL'),
         ('maxSolarRad',          'REAL'),
         ('nh3',                  'REAL'),
         ('no2',                  'REAL'),
         ('noise',                'REAL'),
         ('o3',                   'REAL'),
         ('outHumidity',          'REAL'),
         ('outTemp',              'REAL'),
         ('outTempBatteryStatus', 'REAL'),
         ('pb',                   'REAL'),
         ('p_dayRain 	',         'REAL'),
         ('p_monthRain 	',         'REAL'),
         ('p_rain 	',         'REAL'),
         ('p_rainRate 	',         'REAL'),
         ('p_stormRain 	',         'REAL'),
         ('p_weekRain 	',         'REAL'),
         ('p_yearRain 	',         'REAL'),
         ('ws90_batt',             'REAL'),
         ('ws90cap_volt',          'REAL'),
         ('ws90_sig',              'REAL'),
         ('pm2_5 	',         'REAL'),
         ('pm2_52 	',         'REAL'),
         ('pm2_53 	',         'REAL'),
         ('pm2_54 	',         'REAL'),
         ('pm2_51_24h_avg          'REAL'),
         ('pm2_52_24h_avg ',       'REAL'),
         ('pm2_53_24h_avg ',       'REAL'),
         ('pm2_54_24h_avg ',       'REAL'),
         ('pm2_55_24h_avg ',       'REAL'),
         ('pm2_55 	',         'REAL'),
         ('pm10 	',         'REAL'),
         ('pm10_24h_avg	',         'REAL'),
         ('pm1_0',                'REAL'),
         ('pressure',             'REAL'),
         ('radiation',            'REAL'),
         ('sunshine_hours',       'REAL'),
         ('rain    ',             'REAL'),
         ('rainRate',             'REAL'),
         ('dayRain',              'REAL'),
         ('weekRain',             'REAL'),
         ('monthRain',            'REAL'),
         ('yearRain',             'REAL'),
         ('stormRain',            'REAL'),
         ('totalRain',            'REAL'),
         ('wh40_bat',             'REAL'),
         ('wh40_sig',             'REAL'),
         ('referenceVoltage',     'REAL'),
         ('rxCheckPercent',       'REAL'),
         ('soilTemp1',            'REAL'),
         ('soilTemp2',            'REAL'),
         ('soilTemp3',            'REAL'),
         ('soilTemp4',            'REAL'), 
         ('soilTemp5',            'REAL'),
         ('soilTemp6',            'REAL'),
         ('soilTemp7',            'REAL'),
         ('soilTemp8',            'REAL'),  
         ('wn34_ch1_batt',         'REAL'),
         ('wn34_ch2_batt',         'REAL'),
         ('wn34_ch3_batt',         'REAL'),
         ('wn34_ch4_batt',         'REAL'),
         ('wn34_ch5_batt',         'REAL'),
         ('wn34_ch6_batt',         'REAL'),
         ('wn34_ch7_batt',         'REAL'),
         ('wn34_ch8_batt',         'REAL'),
         ('wn34_ch1_sig',         'REAL'),
         ('wn34_ch2_sig',         'REAL'),
         ('wn34_ch3_sig',         'REAL'),
         ('wn34_ch4_sig',         'REAL'),
         ('wn34_ch5_sig',         'REAL'),
         ('wn34_ch6_sig',         'REAL'),
         ('wn34_ch7_sig',         'REAL'),
         ('wn34_ch8_sig',         'REAL'),
         ('snow',                 'REAL'),
         ('snowBatteryStatus',    'REAL'),
         ('snowDepth',            'REAL'),
         ('snowMoisture',         'REAL'),
         ('snowRate',             'REAL'),
         ('so2',                  'REAL'),
         ('soilMoist1',           'REAL'),
         ('soilMoist2',           'REAL'),
         ('soilMoist3',           'REAL'),
         ('soilMoist4',           'REAL'),
         ('soilMoist5',           'REAL'),
         ('soilMoist6',           'REAL'),
         ('soilMoist7',           'REAL'),
         ('soilMoist8',           'REAL'),
         ('wh51_ch1_batt',         'REAL'),
         ('wh51_ch2_batt',         'REAL'),
         ('wh51_ch3_batt',         'REAL'),
         ('wh51_ch4_batt',         'REAL'),
         ('wh51_ch5_batt',         'REAL'),
         ('wh51_ch6_batt',         'REAL'),
         ('wh51_ch7_batt',         'REAL'),
         ('wh51_ch8_batt',         'REAL'),
         ('wh51_ch1_sig',         'REAL'),
         ('wh51_ch2_sig',         'REAL'),
         ('wh51_ch3_sig',         'REAL'),
         ('wh51_ch4_sig',         'REAL'),
         ('wh51_ch5_sig',         'REAL'),
         ('wh51_ch6_sig',         'REAL'),
         ('wh51_ch7_sig',         'REAL'),
         ('wh51_ch8_sig',         'REAL'),
         ('snow',                 'REAL'),    
         ('supplyVoltage',        'REAL'),
         ('txBatteryStatus',      'REAL'),
         ('UV',                   'REAL'),
         ('uvradiation',          'REAL'),
         ('uvBatteryStatus',      'REAL'),
         ('windBatteryStatus',    'REAL'),
         ('windchill',            'REAL'),
         ('windDir',              'REAL'),
         ('windGust',             'REAL'),
         ('windGustDir',          'REAL'),
         ('windrun',              'REAL'),
         ('windSpeed',            'REAL'),
         ('maxDailyGust',         'REAL'),
         ('wh24_batt',             'REAL'),
         ('wh24_sig',              'REAL'),
         ('wh25_batt',             'REAL'),
         ('wh25_sig',              'REAL'),
         ('wh26_batt',             'REAL'),
         ('wh26_sig',              'REAL'),
         ('wh57__batt',            'REAL'),
         ('wh57__sig',             'REAL'),
         ('wh65_batt',             'REAL'),
         ('wh65_sig',              'REAL'),
         ('wh68_batt',             'REAL'),
         ('wh68_sig',              'REAL'),
         ('ws80_batt',             'REAL'),
         ('ws80_sig',              'REAL'),

         ]

day_summaries = [(e[0], 'scalar') for e in table
                 if e[0] not in ('dateTime', 'usUnits', 'interval')] + [('wind', 'VECTOR')]

schema = {
    'table': table,
    'day_summaries' : day_summaries
}

—————————————————————————————————————————————————————————

the extended Interceptor driver

The interceptor driver by Matthew Wall as available at GitHub has never (so far, March 2024) been updated to the sensor reality of the Ecowitt ecosystem. It still covers only the basic sensors outdoor temp/hum, wind, rain and solar. It has been adapted to conform with changes in Python3 syntax versus Python2 syntax, but that's it.

Also the WiFi firmware of the Ecowitt consoles has been updated several times and includes many new sensors and sensor names and variables like heap, runtime, ws90cap etc. which have not been added to either the field map or the exclusion list and therefore produce error/warning messages in the syslog.

There had been several projects by programmers to extend and update the interceptor driver. We will present here a version which is in synch with the extended Ecowitt database schema proposed here.
In some of the existing solutions different namings of the weewx database field names exist. The same applies to the assigbment of unit groups to the database fields. The unit groups are mentioned in weewx.conf and the chosen units (e.g. degree_C or degree_F for the group_temperature) are assigned there

# **** weewx.conf ****
# .....
[StdReport] 
   # skins
   [[Seasons]]
#   .......
#   .......
   [[Defaults]] 
      [[[Units]]] 
         [[[[Groups]]]]
                group_altitude = meter    # Options are 'foot' or 'meter'
                group_degree_day = degree_C_day    # Options are 'degree_F_day' or 'degree_C_day'
                group_distance = km    # Options are 'mile' or 'km'
                group_pressure = hPa    # Options are 'inHg', 'mmHg', 'mbar', 'hPa', or 'kPa'
                group_rain = mm    # Options are 'inch', 'cm', or 'mm'
                group_rainrate = mm_per_hour    # Options are 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
                group_speed = km_per_hour    # Options are 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
                group_temperature = degree_C    # Options are 'degree_F' or 'degree_C'
                group_moisture = percent
                group_concentration = microgram_per_meter_cubed
#               # etc. 
# ....

we will provide a corresponding extension.py file, where all non-basic sensors will be assigned to the fitting unit group.

#
#    Copyright (c) 2009-2015 Tom Keffer <tkeffer@gmail.com>
#
#    See the file LICENSE.txt for your full rights.
#

"""User extensions module

This module is imported from the main executable, so anything put here will be
executed before anything else happens. This makes it a good place to put user
extensions.
"""

import locale
# This will use the locale specified by the environment variable 'LANG'
# Other options are possible. See:
# http://docs.python.org/2/library/locale.html#locale.setlocale
locale.setlocale(locale.LC_ALL, '')
#"group_count"       : "count",		'] = 'group_count'

import weewx.units
weewx.units.obs_group_dict['soilTemp1'] = 'group_temperature'
weewx.units.obs_group_dict['soilTemp3'] = 'group_temperature'
weewx.units.obs_group_dict['extraTemp17'] = 'group_temperature'
weewx.units.obs_group_dict['extraHumid17'] = 'group_percent'
weewx.units.obs_group_dict['lightning_last_det_time'] = 'group_time'  
weewx.units.obs_group_dict['lightningcount'] = 'group_count'

weewx.units.obs_group_dict['pm2_5'] = 'group_concentration'
weewx.units.obs_group_dict['pm10_0'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_52'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_53'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_54'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_55'] = 'group_concentration'

weewx.units.obs_group_dict['pm2_55_24h_avg'] = 'group_concentration'
weewx.units.obs_group_dict['pm10'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_54_24h_avg'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_53_24h_avg'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_52_24h_avg'] = 'group_concentration'
weewx.units.obs_group_dict['pm2_51_24h_avg'] = 'group_concentration'
weewx.units.obs_group_dict['leafWet1'] = 'group_percent'
weewx.units.obs_group_dict['soilTemp2'] = 'group_temperature'
weewx.units.obs_group_dict['soilTemp4'] = 'group_temperature'
weewx.units.obs_group_dict['daymaxwind'] = 'group_speed'

still incomplete - example of a partially extended extensions.py content only

The combination of a wview_ecowitt database schema, an extended extensions.py unit group definition and an extended field_map and exclusion list in interceptor.py will make it possible to store/archive all existing Ecowitt sensors in a weewx database and display the sensor data in the reports and skins (default skin: Seasons).

to be completed
—————————————————————————————————————————————————————————

a sample weewx.conf file (excerpt) for Ecowitt stations

general high level overview of weewx.conf sections / stanzas

[station]
# .......
debug = 0               # debug level logging in syslog 0,1,3
station_type = GW1000   # or Interceptor for Ecowitt consoles
# .......
[Simulator]             # weewx test station
# .......
[GW1000]                # station type stanza - more than one can be set, only one station_type active
# .......               # driver used, IP address of console, polling interval etc.
[Interceptor]
# .......
[StdRESTful]        # posting to Weather Services
# .......
   [[CWOP]]         # also WU, AWEKAS ... - a reporting service is needed --> [Engine]
# .......
[StdReport]         # skins used including FTP upload: "FTP skin" 
  HTML_ROOT = /var/weewx/reports  # location of skin/web pages default for all skins, can be changed at skin level 
  [[Seasons]]   
     enable = true   
# .......
  [[Defaults]]
    [[[Units]]]     # assign units to unit_groups (e.g. group_temperature = degree_C)
    [[[Labels]]]    # give your variables/observations custom names (e.g. ExtraTemperature1 = Balcony)
# .......
[StdConvert]        # target unit system
target_unit = US    # Options are 'US', 'METRICWX', or 'METRIC'
# .......           # affects database only, not the reports
[StdCalibrate]
   [[Corrections]]  # corrections of variables, re-assignment of variables
                    # e.g. for GW1000: radiation = luminosity / 126.7 if luminosity not None else None
# .......           # lightning_distance = lightning_distance if lightning_strike_count > 0 else None
[StdQC              # quality control]
# .......
[StdWXCalculate]    
    [[Calculations]]  # How to calculate derived quantities.  Possible values are:
                      #  hardware - use the value provided by hardware (usually the console) 
                      #  software - use the value calculated by weewx
                      #  prefer_hardware - use value provided by hardware if available, otherwise use  weewx calculated value
# .......
[StdTimeSynch]
# .......
[StdArchive]                   # define archivng interval, default = 300 seconds/5 minutes
   archive_interval = 300      # record generation hardware/software, database binding
# ....... 
[DataBindings]                 # define symbolic database type 
  [wx_binding]]                # one (or more bindings possible --> multi instance reporting)  
     database = archive_sqlite # The database must match one of the sections in [Databases].
     schema = schemas.wview_extended.schema  # database schema used for database creation
# .......                                    # proposed schema: schemas.wview_ecowitt.schema
[Databases]
   [[archive_sqlite]]
        database_name = weewx.sdb
        database_type = SQLite
# .......
    [[archive_mysql]]            # MySQL
        database_name = weewx
        database_type = MySQL
# .......
[DatabaseTypes]
    [[SQLite]]                         # Defaults for SQLite databases
        driver = weedb.sqlite
        SQLITE_ROOT = /var/lib/weewx   # Directory in which the database files are located
    [[MySQL]]
# .......
[Engine]      
   [[Services]] # service modules used and running order
     report_services = weewx.engine.StdPrint, weewx.engine.StdReport
# .......
[Accumulator]             # how to handle observations collected in an archive cycle in the loop/archive tables
    [[outTemp]]           # overrides the default accumulators; possible values e.g. min, max, avg, sum, last ...
        extractor = max
    [[radiation]]
        extractor = max
    [[daymaxwind]]
        extractor = last
    [[lightning_distance]]
        extractor = last
    [[lightning_strike_count]]
        extractor = sum
    [[lightningcount]]
        extractor = last
    # .......    

weewx.conf examples for [GW1000] and [Interceptor] drivers

GW1000 (for GW1000, GW1100, GW1200; GW2000, WN19x0; WN182x, WS3800, WS39x0)
install the driver with the respective weewx tool !!!

[station]
# .......
debug = 0               # debug level logging in syslog 0,1,3
station_type = GW1000   
# .......
[GW1000]
    driver = user.gw1000
    poll_interval = 5
    ip_address = xxx.xxx.xxx.xxx   # e.g. 192.168.1.23
    iface = eth0                   # or wlan0 if WLAN interface used
# .......    
[StdReport]         # skins used including FTP upload: "FTP skin" 
  HTML_ROOT = /var/weewx/reports  # location of skin/web pages default for all skins, can be changed at skin level 
  [[Seasons]]   
     enable = true   
# .......
  [[Defaults]]
    [[[Units]]]     # assign units to unit_groups (e.g. group_temperature = degree_C)
    [[[Labels]]]    # give your variables/observations custom names (e.g. ExtraTemperature1 = Balcony)
# .......
[StdConvert]        # target unit system
target_unit = US    # Options are 'US', 'METRICWX', or 'METRIC'
# .......           # affects database only, not the reports
[StdCalibrate]
   [[Corrections]]  # corrections of variables, re-assignment of variables
        radiation = luminosity / 126.7 if luminosity not None else None
        lightning_distance = lightning_distance if lightning_strike_count > 0 else None
# .......           
[StdQC              # quality control]
# .......
[StdWXCalculate]    
    [[Calculations]]  # How to calculate derived quantities.  Possible values are:
                      #  hardware - use the value provided by hardware (usually the console) 
                      #  software - use the value calculated by weewx
                      #  prefer_hardware - use value provided by hardware if available, otherwise use  weewx calculated value
                      pressure = prefer_hardware
        altimeter = prefer_hardware
        appTemp = prefer_hardware
        barometer = prefer_hardware
        cloudbase = prefer_hardware
        dewpoint = prefer_hardware
        ET = prefer_hardware
        heatindex = prefer_hardware
        humidex = prefer_hardware
        inDewpoint = prefer_hardware
        maxSolarRad = prefer_hardware
        rainRate = prefer_hardware
        windchill = prefer_hardware
        windrun = prefer_hardware
# .......
[StdTimeSynch]
# .......
[StdArchive]                   # define archivng interval, default = 300 seconds/5 minutes
   archive_interval = 300      # record generation hardware/software, database binding
# ....... 
[DataBindings]                 # define symbolic database type 
  [wx_binding]]                # one (or more bindings possible --> multi instance reporting)  
     database = archive_sqlite # The database must match one of the sections in [Databases].
     schema = schemas.wview_ecowitt.schema  # database schema used for database creation
# .......                       

Interceptor (for all consoles with Customized server option)
install the driver with the respective weewx tool !!!

[station]
# .......
debug = 0               # debug level logging in syslog 0,1,3
station_type = Interceptor   
# .......
[Interceptor]
    driver = user.interceptor
    ip_address = xxx.xxx.xxx.xxx   # e.g. 192.168.1.23
    iface = eth0                   # or wlan0 if WLAN interface used
    port = 8000                    # same port as chosen in console Customized Server
    mode = listen
# .......    
[StdReport]         # skins used including FTP upload: "FTP skin" 
  HTML_ROOT = /var/weewx/reports  # location of skin/web pages default for all skins, can be changed at skin level 
  [[Seasons]]   
     enable = true   
# .......
  [[Defaults]]
    [[[Units]]]     # assign units to unit_groups (e.g. group_temperature = degree_C)
    [[[Labels]]]    # give your variables/observations custom names (e.g. ExtraTemperature1 = Balcony)
# .......
[StdConvert]        # target unit system
target_unit = US    # Options are 'US', 'METRICWX', or 'METRIC'
# .......           # affects database only, not the reports
[StdCalibrate]
   [[Corrections]]  # corrections of variables, re-assignment of variables
                    # only for station_type GW1000: radiation = luminosity / 126.7 if luminosity not None else None
        lightning_distance = lightning_distance if lightning_strike_count > 0 else None
# .......           
[StdQC              # quality control]
# .......
[StdWXCalculate]    
    [[Calculations]]  # How to calculate derived quantities.  Possible values are:
                      #  hardware - use the value provided by hardware (usually the console) 
                      #  software - use the value calculated by weewx
                      #  prefer_hardware - use value provided by hardware if available, otherwise use  weewx calculated value
                      pressure = prefer_hardware
        altimeter = prefer_hardware
        appTemp = prefer_hardware
        barometer = prefer_hardware
        cloudbase = prefer_hardware
        dewpoint = prefer_hardware
        ET = prefer_hardware
        heatindex = prefer_hardware
        humidex = prefer_hardware
        inDewpoint = prefer_hardware
        maxSolarRad = prefer_hardware
        rainRate = prefer_hardware
        windchill = prefer_hardware
        windrun = prefer_hardware
# .......
[StdTimeSynch]
# .......
[StdArchive]                   # define archivng interval, default = 300 seconds/5 minutes
   archive_interval = 300      # record generation hardware/software, database binding
# ....... 
[DataBindings]                 # define symbolic database type 
  [wx_binding]]                # one (or more bindings possible --> multi instance reporting)  
     database = archive_sqlite # The database must match one of the sections in [Databases].
     schema = schemas.wview_ecowitt.schema  # database schema used for database creation
# .......   

proposed options for data accumulation in the loop/archive table
(to be added to weewx.conf)

# Options for GW1000 and Interceptor drivers
[Accumulator]
    [[outTemp]]
        extractor = max
    [[radiation]]
        extractor = max
    # Start Ecowitt Gateway driverextractors
    [[daymaxwind]]
        extractor = last
    [[lightning_distance]]
        extractor = last
    [[lightning_strike_count]]
        extractor = sum
    [[lightningcount]]
        extractor = last
    [[lightning_last_det_time]]
        extractor = last
    [[stormRain]]
        extractor = last
    [[hourRain]]
        extractor = last
    [[dayRain]]
        extractor = last
    [[weekRain]]
        extractor = last
    [[monthRain]]
        extractor = last
    [[yearRain]]
        extractor = last
    [[totalRain]]
        extractor = last
    [[p_rain]]
        extractor = sum
    [[p_stormRain]]
        extractor = last
    [[p_dayRain]]
        extractor = last
    [[p_weekRain]]
        extractor = last
    [[p_monthRain]]
        extractor = last
    [[p_yearRain]]
        extractor = last
    [[t_rain]]
        extractor = sum
    [[t_stormRain]]
        extractor = last
    [[t_dayRain]]
        extractor = last
    [[t_weekRain]]
        extractor = last
    [[_monthRain]]
        extractor = last
    [[t_yearRain]]
        extractor = last
    [[pm2_51_24h_avg]]
        extractor = last
    [[pm2_52_24h_avg]]
        extractor = last
    [[pm2_53_24h_avg]]
        extractor = last
    [[pm2_54_24h_avg]]
        extractor = last
    [[pm2_55_24h_avg]]
        extractor = last
    [[pm10_24h_avg]]
        extractor = last
    [[co2_24h_avg]]
        extractor = last
    [[wh40_batt]]
        extractor = last
    [[wh26_batt]]
        extractor = last
    [[wh25_batt]]
        extractor = last
    [[wh24_batt]]
        extractor = last
    [[wh65_batt]]
        extractor = last
    [[wh31_ch1_batt]]
        extractor = last
    [[wh31_ch2_batt]]
        extractor = last
    [[wh31_ch3_batt]]
        extractor = last
    [[wh31_ch4_batt]]
        extractor = last
    [[wh31_ch5_batt]]
        extractor = last
    [[wh31_ch6_batt]]
        extractor = last
    [[wh31_ch7_batt]]
        extractor = last
    [[wh31_ch8_batt]]
        extractor = last
    [[wn34_ch1_batt]]
        extractor = last
    [[wn34_ch2_batt]]
        extractor = last
    [[wn34_ch3_batt]]
        extractor = last
    [[wn34_ch4_batt]]
        extractor = last
    [[wn34_ch5_batt]]
        extractor = last
    [[wn34_ch6_batt]]
        extractor = last
    [[wn34_ch7_batt]]
        extractor = last
    [[wn34_ch8_batt]]
        extractor = last
    [[wn35_ch1_batt]]
        extractor = last
    [[wn35_ch2_batt]]
        extractor = last
    [[wn35_ch3_batt]]
        extractor = last
    [[wn35_ch4_batt]]
        extractor = last
    [[wn35_ch5_batt]]
        extractor = last
    [[wn35_ch6_batt]]
        extractor = last
    [[wn35_ch7_batt]]
        extractor = last
    [[wn35_ch8_batt]]
        extractor = last
    [[wh41_ch1_batt]]
        extractor = last
    [[wh41_ch2_batt]]
        extractor = last
    [[wh41_ch3_batt]]
        extractor = last
    [[wh41_ch4_batt]]
        extractor = last
    [[wh45_batt]]
        extractor = last
    [[wh51_ch1_batt]]
        extractor = last
    [[wh51_ch2_batt]]
        extractor = last
    [[wh51_ch3_batt]]
        extractor = last
    [[wh51_ch4_batt]]
        extractor = last
    [[wh51_ch5_batt]]
        extractor = last
    [[wh51_ch6_batt]]
        extractor = last
    [[wh51_ch7_batt]]
        extractor = last
    [[wh51_ch8_batt]]
        extractor = last
    [[wh51_ch9_batt]]
        extractor = last
    [[wh51_ch10_batt]]
        extractor = last
    [[wh51_ch11_batt]]
        extractor = last
    [[wh51_ch12_batt]]
        extractor = last
    [[wh51_ch13_batt]]
        extractor = last
    [[wh51_ch14_batt]]
        extractor = last
    [[wh51_ch15_batt]]
        extractor = last
    [[wh51_ch16_batt]]
        extractor = last
    [[wh55_ch1_batt]]
        extractor = last
    [[wh55_ch2_batt]]
        extractor = last
    [[wh55_ch3_batt]]
        extractor = last
    [[wh55_ch4_batt]]
        extractor = last
    [[wh57_batt]]
        extractor = last
    [[wh68_batt]]
        extractor = last
    [[ws80_batt]]
        extractor = last
    [[ws90_batt]]
        extractor = last
    [[wh40_sig]]
        extractor = last
    [[wh26_sig]]
        extractor = last
    [[wh25_sig]]
        extractor = last
    [[wh24_sig]]
        extractor = last
    [[wh65_sig]]
        extractor = last
    [[wh31_ch1_sig]]
        extractor = last
    [[wh31_ch2_sig]]
        extractor = last
    [[wh31_ch3_sig]]
        extractor = last
    [[wh31_ch4_sig]]
        extractor = last
    [[wh31_ch5_sig]]
        extractor = last
    [[wh31_ch6_sig]]
        extractor = last
    [[wh31_ch7_sig]]
        extractor = last
    [[wh31_ch8_sig]]
        extractor = last
    [[wn34_ch1_sig]]
        extractor = last
    [[wn34_ch2_sig]]
        extractor = last
    [[wn34_ch3_sig]]
        extractor = last
    [[wn34_ch4_sig]]
        extractor = last
    [[wn34_ch5_sig]]
        extractor = last
    [[wn34_ch6_sig]]
        extractor = last
    [[wn34_ch7_sig]]
        extractor = last
    [[wn34_ch8_sig]]
        extractor = last
    [[wn35_ch1_sig]]
        extractor = last
    [[wn35_ch2_sig]]
        extractor = last
    [[wn35_ch3_sig]]
        extractor = last
    [[wn35_ch4_sig]]
        extractor = last
    [[wn35_ch5_sig]]
        extractor = last
    [[wn35_ch6_sig]]
        extractor = last
    [[wn35_ch7_sig]]
        extractor = last
    [[wn35_ch8_sig]]
        extractor = last
    [[wh41_ch1_sig]]
        extractor = last
    [[wh41_ch2_sig]]
        extractor = last
    [[wh41_ch3_sig]]
        extractor = last
    [[wh41_ch4_sig]]
        extractor = last
    [[wh45_sig]]
        extractor = last
    [[wh51_ch1_sig]]
        extractor = last
    [[wh51_ch2_sig]]
        extractor = last
    [[wh51_ch3_sig]]
        extractor = last
    [[wh51_ch4_sig]]
        extractor = last
    [[wh51_ch5_sig]]
        extractor = last
    [[wh51_ch6_sig]]
        extractor = last
    [[wh51_ch7_sig]]
        extractor = last
    [[wh51_ch8_sig]]
        extractor = last
    [[wh51_ch9_sig]]
        extractor = last
    [[wh51_ch10_sig]]
        extractor = last
    [[wh51_ch11_sig]]
        extractor = last
    [[wh51_ch12_sig]]
        extractor = last
    [[wh51_ch13_sig]]
        extractor = last
    [[wh51_ch14_sig]]
        extractor = last
    [[wh51_ch15_sig]]
        extractor = last
    [[wh51_ch16_sig]]
        extractor = last
    [[wh55_ch1_sig]]
        extractor = last
    [[wh55_ch2_sig]]
        extractor = last
    [[wh55_ch3_sig]]
        extractor = last
    [[wh55_ch4_sig]]
        extractor = last
    [[wh57_sig]]
        extractor = last
    [[wh68_sig]]
        extractor = last
    [[ws80_sig]]
        extractor = last
    [[ws90_sig]]
        extractor = last
# End Ecowitt Gateway driverextractors 

running multiple instances of weewx to combine observations from different weather stations in one skin/webpage
to be completed

changes with weewx version 5


the configuration files skin.conf, index.html.tmpl and its includes (*.inc) have been even more parametrized than already in version 4 earlier and have become even less understandable for a non-Python programming language geek.

From a programmer's/programming point of view this is conclusive and elegant, but, if some modification is needed, the weewx world has become more intransparent for the average user who is not a Linux and/or Python nerd.

That being said, weewx is a highly complex and also highly capable piece of (weather) software which allows a lot of customization for those who know how to do (and know what they do and why). Definitely a great piece of work what Tom, Matthew and Gary have produced - not to mention the many developers of extensions to connect different devices and to allow for different kinds of skins (web pages).

from version 4 to version the different separately used weewx tools or utilities have been reworked and assembled under a central tool by the name weectl

in weewx-lingo that goes (quote from the weewx documentation)

the command weectl is the entry point for most WeeWX utilities. To see the various utilities available, run it with the –help option:

$ weectl –help usage: weectl -v|–version

     weectl -h|--help
     weectl database --help
     weectl debug --help
     weectl device --help
     weectl extension --help
     weectl import --help
     weectl report --help
     weectl station --help

weectl is the master utility used by WeeWX. It can invoke several different subcommands listed below. You can explore their utility by using the –help option. For example, to find out what the 'database' subcommand can do, use 'weectl database –help'.

optional arguments:

1. h, –help show this help message and exit
2. v, –version show program's version number and exit

Available subcommands:

{database,debug,device,extension,import,report,station}
  database            Manage WeeWX databases.
  debug               Generate debug info.
  device              Manage your hardware.
  extension           List, install, or uninstall extensions.
  import              Import observation data.
  report              List and run WeeWX reports.
  station             Create, modify, or upgrade a station data area.

work in progress - to be completed

Weather Display (current version 10.37S152 Windows - February 2025) is a Weather presentation and data logging software written by Brian Hamilton, NZ. It supports several weather stations and meanwhile, after about five years all modern Ecowitt consoles and their connection protocols. In 2019 it had started with supporting the GW1000 API and meanwhile also supports the Customized Server connection for Wunderground, Ecowitt and Ambient protocols and the data collection from the Ecowitt cloud (permanent and backfill).

There is also a version for running on Linux derivate OS.

website: https://www.weather-display.com/

Its display (dashboard) can be interactively customized in a very detailed manner.

setting up a modern Ecowitt station:
there are four options, depending on console and data source used

1. local Ecowitt API (GW1000, telnet …)
2. Customized Server option
3. data supply from the Ecowitt cloud at ecowitt.net
4. supplementary missed data backfilling option

from the “Control Panel” menu item select the “Station type and Settings” icon



the terminology used when configuring the Customized server option is a bit strange from what is normally used in the Ecowitt ecosystem

using Weather Display with the Customized Server option providing data
red circle –> mark “Enabled” –> press “Setup” - the below dialog opens

using Weather Display with the local Ecowitt API option providing data
blue circle –> mark “Enabled” –> enter IP address of the console/gateway

when the GW1000 option (blue circle) is selected, at program restart the below interface also opens. It comes from the crongw1000.exe program running in parallel and is fetching the data from the console/gateway. It can be minimized as the main data display is on the dashboard and its subpages.
in the interface options for using a WS90 outdoor array with piezo rain sensor (Wittboy) have to chosen if such an array is being used
crongw1000.exe must run together with the main program. Otherwise the data won't be updated nor stored.

if WD is supposed to download data from the Ecowitt cloud at (re-)startup after a longer break before reading again current data, the backfill option has to be tagged

the WD local Ecowitt API / GW1000 API interface

————————————————————————————————————————————————————————————————-

HomeAssistant

HomeAssistant (HA) is free and open-source software for home automation, designed to be an Internet of things (IoT) ecosystem-independent integration platform and central control system for smart home devices, with a focus on local control and privacy. The Home Assistant software application is installed as a (computer) appliance. HA is often installed inside a docker container on a NAS server or a RaspberyyPi.

Recently there out two out-of-the-box appliances available:
HomeAssistant GREEN with HA pre-installed, 32 GB internal storage and a backup SD card interface and a LAN Ethernet connection (~ 100 USD/EUR).
The HA GREEN comes with HomeAssistant pre-installed

HomeAssistant YELLOW: a modular hardware setup based on a RaspeberryPi computing module and offering M2-SSD and PoE power supply options

For both GREEN and YELLOW other protocol communication like ZigBee is available via pluggable add-ons.

Sensors and Hubs (consoles/gateway) connect to HA via so-called integrations where the consoles/gateways are described and depicted in the HA lingo as devices and the sensors as entities.

Meanwhile (August 2025) there are several Ecowitt-related integrations:
1. the Home Assistant Ecowitt (core) integration originally provided by the HA co-founder pvizeli with a stagnating development sine ~2022/2023 based on the Customized Server interface
(this has changed with Home Assistant core upgrade 2025.10.1 where a lot of missing entities were added - see below)

2. the Ecowitt Official Integration provided as a recent (September 2025) custom integration via HACS based on the http local APIs

There is some strange history to these two integrations described later with the Ecowitt Original Integration (a.k.a. Ecowitt IoT integration).

3. FOSHKplugin
(needs a separate Linux-based server, e.g. a NAS, a RaspberryPi …)
It works with the Ecowitt Customized Server, which every Ecowitt console with WLAN/LAN interface has, supports all Ecowitt sensors and IoT devices - via MQTT integration in HA see below (link)

4. integrate (Fine Offset manufactured) Ambient Weather stations into Home Assistant

————————————————————————————————————————————————————————————————-
1. the Ecowitt (core) integration [NOT supported by Ecowitt]

Ecowitt consoles send their data to the so-called “Ecowitt integration” in HA using the customized server functionality (link to Custom Server) of each LAN/WLAN enabled console. The console will be registered a a device under the Ecowitt integration and establishes the connection via a so-called webhook which will be provided by HA during installation of the device (HA term) inside the Ecowitt integration. (Be careful to note this webhook down right away as it cannot be found anymore later on and you will have delete and reinstall the integration). You can (in principle) use an unlimited number of devices inside the Ecowitt integration. One per console.
Like this you can integrate readings from different consoles into one view on a dashboard (see picture below where the readings of three different consoles has been integrated in one dashboard.

By default HA uses port 8123 to communicate with an Ecowitt console.
(strictly speaking the default port where HA expects to receive Ecowitt console posts is 8123 for the Ecowitt integration)

HA instructions on How to use the HA Ecowitt integration

Once HA receives data from an Ecowitt console (device), it will display a list of all sent sensors under that device In HA a sensor is an entity. The sensors will be named using a console/firmware combination as a start and then the sensor function.

Supported devices: all consoles who have the 3rd party posting (customized server) installed except the WS6006.

for a definition of Home Assistant terms follow the link



(take note that the firmware info on the device info is not the console (here GW2000) firmware but the firmware of the connected WS90 sensor array, and the battery status refers to the backup battery of the WS90)


Attention: in the current Ecowitt core integration (March 2024) the daily accumulated rain is wrongly named rain_rate.
Now you can choose available dashboard elements (tiles, HA term: cards) of different types to depict your sensors: sensors, statistics, tables, instruments etc.




the current version of the Ecowitt HA core integration does NOT cover all possible Ecowitt sensors and posted variable names - respective issues have been posted with the code owner at GitHub - e.g.
[home-assistant/core] Ecowitt integration - sensors from customized server string missing/not handled (Issue #114037)

below the missing customized server post string variables:

with the Home Assistant core upgrade 2025.10.1 a host of missing sensors (entities) were added, some with some strange naming* though - however, the Soil AD sensor values are not yet properly handled - they appear as disabled entities !
*) the WH31 and WH32, WH32-EP sensors are all named with -EP even when they are not the EP model.
the consoles cannot tell the difference between a normal or an EP sensor - neither can then Home Assistant
a naming like WH31(-EP) or WH32(-EP) would be more helpful

*) proposed name
example: diagnostic HomeAssistant file: HA_diagnostic_file_WS3910
the soilMoist9-16, the WH54 LDS01-Ch1-4 and the custom server posting interval (interval) are also missing

an admittedly rather extreme example of combining 56 WH51 soil moisture sensors in a Home Assistant dashboard:

————————————————————————————————————————————————————————————————-

2. the Ecowitt Official Integration (HACS) [built and maintained by Ecowitt]

History:
Originally Ecowitt wanted to participate in the development of the Ecowitt (core) Integration, but as some recent communication seems to reveal due to certain misunderstandings regarding development rules for HA core applications or integrations Ecowitt engineering was excluded from the development.

As a result, Ecowitt recently developed their “alternative” original integration taking the HACS path, the Home Assistant Community Store.

It appears that acknowledging certain potential misunderstanding and miscommunication, HomeAssistant officials are showing interest in solving the historically grown situation and a looking for partnering with Ecowitt in order to have an updated Ecowitt core integration or even two depending on the connectivity approach. Conversations for deeloping a partnership are about to start.

The Ecowitt original integration is based on http calls to the local device API and the local IoT API.
For a list of consoles supporting the local http API follow the link
Therefore, the WS2320, WS2910, HP350x and HP25x0 display consoles and the GW1000/WH2650 gateways are not supported. Reason is the old hardware and its insufficient memory. Because of this the local http API could not be implemented.
They would still need the Ecowitt core integration based on the customized server post or the FOSHKplugin-MQTT solution..
The Ecowitt Original Integration (HACS) repository can be found at https://github.com/Ecowitt/ha-ecowitt-iot
Meanwhile, January 2026, the Ecowitt original integration (V. 1.0.27) is complete as for the data display. 99% of the expected functionality is already available.

What is still missing are

• the signal quality and RSSI data of each sensor 1.0.17
• the signal quality and RSSI data of the sensor array 1.0.19
• the battery status and voltage (where applicable) of the arrays (WN67/WS68/WS69/WS80/WS85/WS90) 1.0.14
• the capacitor voltage of the WS85/WS90*
• the firmware version of the WS85/WS90 (shown in the WebUI !)
• the start rain indicator or raining status for the WS85/WS90 (srain) 1.0.14
• the PM25,1,4,10 24H average values of the WH45/46/46D 1.0.15
• the PM25 24H average value of the WH41/43 (PM25 24H AQI is available) 1.0.17
• LDS01 height (air is available) 1.0.17
• LDS01 heater count with certain consoles (with a GW3000 available, with GW1100, WS6210 missing - missing firmware feature)

*) the inclusion of the WS85/WS90 capacitor voltage into the integration seems to be more a political issue than a technical or engineering issue. So far Ecowitt wants to show only what is also visible in the WebUI and therefore categorically excludes the capacitor voltage from being displayed in the integration.
An easy solution would simply be to include the capacitor voltage into the WebUI display (minor effort) as this is a special piece of information for the WS85/WS90. For the WS6210 console/gateway also the specially important voltages of the batteries have been added to the WebUI.

Also, as of 28-Aug-2025, there is no extended IoT functionality beyond switching the device on and off for HA developed yet, but this could be on the integration roadmap for 2025 (phase 2). Connected IoT device data are already be displayed (see below) and the device can be switched on or off.

If you are familiar with the automation features in Home Assistant, you can already create your own scheduled or smart plans for the IoT devices. Automations can be setup to switch on/off devices based on time (start/end/duration) [scheduled plans] or dependent on other sensor values [smart plans] available in Home Assistant (i.e. not only on Ecowitt sensor data)

As for the provided data, the goal of Ecowitt is to provide all the information which you can see in the WS View Plus app or the WebUI of the connected console.

With version 1.0.19 the integration user interface has undergone a redesign. On the integration level you add devices (consoles). The entry is shown as device and the number of related entities (sensor data). If there are IoT devices connected to the console, the appear in a separate line for each one along with their entities.
under the device category (click on the device entry) there are “Sensors”, “Diagnostic” and “Connected Devices”.
In the category “Sensors” fall all available sensors with weather related data except for the IoT devices.
In the category “Diagnostic” fall all battery status (bars), signal quality and signal strength (RSSI) information of the sensors
In the category “Connected Devices” fall the IoT devices which again have a “Sensors”, “Diagnostic” and for the IoT devices a category “Configuration” has been added - in version 1.0.19 the connected device can be already manually switched on or off.

with version 1.0.28 (27-Feb-2026) all Ecowitt sensors including WN38 and WH52 with derived observation (e.g. WBGT) are available.

entities available in version 1.0.19 (28-Aug-2025)



connected IoT devices

————————————————————————————————————————————————————————————————-
feeding HomeAssistant from selected Ecowitt consoles via MQTT protocol

Ecowitt has started to publish and provide also MQTT protocol for posting data in the customized server section. To use this with HA one would need to create a customized configuration file in YAML at the HA end to define and make available all data sent by the console as a displayable HA entity.

This feature will only be available for the IoT enabled consoles/gateways as only they have enough RAM for such an operation.

A more comfortable way would be to use FOSHKplugin for that purpose. There is a ready-made description how to create all these entities in HA when using the HA MQTT integration via FOSHKplugin (follow the link and search for “Further processing of data from FOSHKplugin in Home Assistant”). Then your don't need to do the tedious work of creating a complex configuration file in YAML. The caveat is that your need an extra server to run FOSHKplugin. You don't need a console posting in MQTT format but the “normal” Ecowitt protocol via Customized Server would be sufficient.

Note that for all MQTT implementations a MQTT server is needed - it is not provided by default by HomeAssistant but must either be separately installed in HA or an otherwise/elsewhere existing MQTT server used (public, private)

HomeAssistant can only connect to ONE MQTT broker as a client - if you need to connect to more than one*, you will need to install (or use) an extra MQTT broker (in the below picture the “local broker”) which runs in bridge mode (it acts as a MQTT client towards another [second] MQTT broker and locally as a broker server)
* sample scenario:
you own a photovoltaic power plant on your balcony with a managed energy storage and you can retrieve the data (power produced, power stored in battery, power sent pass-through via a micro-inverter to the grid etc.) and display in HA - you need to use the MQTT broker of the storage solution provider (e.g. Zendure). If you want to use FOSHKplugin to post Ecowitt console data (plus add-on information) via MQTT in parallel at the same time, this cannot be done via the remote broker of the energy storage solution provider - you need to connect with FOSHKplugin to a local MQTT broker and continue retrieving the data from the remote broker - hence the bridge solution

————————————————————————————————————————————————————————————————-
needing an https connection when the posting console resides outside the local network or when HA is configured for secure external connections

Ecowitt consoles post in http only - not in https. In the future also MQTT will be possible, however also without encryption.
To solve the http/https issue an https-proxy server can be installed which as a man-in-the-middle converts http calls into https. A badly documented but working example is he so-called add-on-Ecowitt-proxy

you can read the documentation before the installation only if you are familar with GitHub and GitHub tools or you know how to read the program code. Otherwise you have to be trustful enough to just install the add-on and only then read the documentation. Technical the add-on does what it is meant to do.

On the HomeAssistant Page for the Ecowitt integration,
the use of the NGINX TLS Proxy Add-on to support HTTPS and HTTP at the same time is recommended.
(Nginx TLS proxy)

the Ecowitt integration developer link at GitHub
there is an alternative Ecowitt integration available, but it's more than 5 years old

————————————————————————————————————————————————————————————————-

Ecowitt IoT devices in Home Assistant

there is an HA IoT integration offered at GitHub,
however, no progress to be noticed …

On the other hand, the new Ecowitt IoT integration (see above) displays already connected IoT sensors (AC1100, WFC01, WFC02). In a second phase also the management of the IoT sensors is planned.
With the respective know-how (IoT http API and Home Assistant automation) one could also implement this oneself.


Note: Probably the new Ecowitt Original Integration (HACS) will soon cover the IoT functionalities.

So far only the basic functionality of getting the readings and manually handling the WFC01 is implemented. There are some timeout issues in the HA-hub connection, but there are already solutions available to be implemented.
The higher functionalities like scheduled plans and smart plans are not yet implemented.
Neither is the handling of an AC1100 which should be analogous to the WFC01, even simpler.
We will report the progress status here. Status now as of 21-May-2025.

————————————————————————————————————————————————————————————————-

how to integrate an Ecowitt WS90 Powered by Shelly into Home Assistant (link)

————————————————————————————————————————————————————————————————-

alternative HA dashboard cards for weather observations or webcams

some cards for the HA dashboard nicer than the default cards by Renato Rossi and featuring the following:

• Display summary weather information
• Display detailed current weather data
• Display detailed forecast weather data
• Display detailed forecast sea weather data
• Display Ultraviolet Radiation
• Display Air Quality data
• Display Pollen data
• Display Alerts
• Display a camera meteogram
• Display your preferred camera

be aware that add-ons cannot be installed in HomeAssistant installations based on Docker containers

————————————————————————————————————————————————————————————————-
the Ecowitt - Home Assistant context - high level design

——————————————————————————————————————————————————————————————-

4. integrate (Fine Offset manufactured) Ambient Weather stations into Home Assistant

1. use the “official” Ambient integration by downloading data from AWN by the help of an API and an APP key

2. use the ecowitt2mqtt tool to receive, convert and post the console data as MQTT posts to Home Assistant

3. use FOSHKplugin (see above under Ecowitt / MQTT) to convert data posted by the console in Ambient protocol and create ready-useable Home Assistant entities posted as MQTT topics

————————————————————————————————————————————————————————————————-

to be completed

open Home Automation Bus (openHAB) is a software solution written in Java that connects building automation components from a wide range of providers in a manufacturer- and protocol-neutral platform.

As many other software system openHAB uses its own set of terms - the openHAB terminology. It consists of terms/elements like Bindings, Things (e.g. device, console), Channels, Items (e.g. weather observations, [set of] variables, Rules and Pages (e.g. a web page). For more details see https://www.openhab.org/docs/

openHAB collects data from Ecowitt weather stations via so-called Bindings

A binding is an application which processes device (here console) data which were either received via a query (poll) or via a conole posting (post) and assigns them to variables which are then used to depict the sensor data and history.
————————————————————————————————————————————————————————————————-

the Fine Offset Weather station Binding
uses the local Ecowitt API

To be used with all consoles/gateways which possess the local Ecowitt API.

The description of the binding at https://www.openhab.org/addons/bindings/fineoffsetweatherstation/ uses sometimes strange wording (e.g. calls the officially named tcpip or telnet or local Ecowitt gateway protocol “wire protocol”) and uses a wrong count of compatible devices. It appears that the (incomplete and not always correct) list of supported device (consoles/gateways) has not been created going by possession of the API or not having the API.

It also says: “This binding works offline by implementing the wire protocol (opens new window) of the WiFi gateway device.” Another unusual and potentially confusing wording or strange definition of the word “offline” (possibly wanting to say “without internet connection” - but both the openHAB server and the Ecowitt console/gateway need to be online = connected to the local network in order for the binding to work).

There is also a mix-up of consoles/gateway names and station model names. E.g. the GW2001 station and the Wittboy are shown as supported devices. Wittboy is the WS90 sensor and in itself is not supported - only via a console/gateway it can be supported. The GW2000 would be such a console (GW2001 is the station model name of GW2000 + WS90), but the GW2000 is even not listed.
Station = console + sensor(s)
the confusion continues …

the ELV WS980 (a WS2320 clone) is flagged as “tested”. Not sure what that means as the WS2320 has a different API from the API the other local Ecowitt API consoles have - but maybe the binding has both APIs implemented …

these points of criticism above do not mean that the binding doesn't work. It obviously works - and will still need to integrate the WS85 array and the WH46.

The complete list of supported devices can be found here in this WiKi - see link above.

a simple rule-of-thumb applies:
When WS View Plus displays the live data of the device in the local network, the device is compatible.
If only weather services and customised server can be configured in the WS View Plus app, the device is NOT compatible with this binding.
————————————————————————————————————————————————————————————————-

the ipObserver Binding
uses the customized server functionality with Wunderground protocol of all modern Ecowitt (clone) consoles
(as per ipObserver documentation on GitHub).
see https://www.openhab.org/addons/bindings/ipobserver/

Therefore the sensors will be limited to the sensors contained in a WU post as the binding intercepts the WU post.

to be used with consoles which do not possess the local Ecowitt API (HP25x0, HP2320, WS2910, HP350x).

The simplest solution to circumvent the restrictions of the ipObserver bindings is to purchase an additional GW1200 gateway, register also all the sensors the console above (especially the HP25x0 and HP350x consoles) has registered and use the Fine Offset Weather Station binding instead.

————————————————————————————————————————————————————————————————-

FOSHKplugin is a small but very powerful tool written in Python by Oliver Engel (known in many weather forums under “olicat”). It is designed to run as a service under any Linux derivate and has amongst other things an inbuilt webserver. The name comes from the original name (manufacturer, owner, group) of the nowadays known Ecowitt brand Fine Offset Hongkong before they relocated to Shenzhen in mainland China.

It is meant to process the custom data which every Ecowitt (clone) console can post in the so-called Ecowitt* or in the WU protocol.
(*) Ambient branded consoles (WS-2000, WS-5000, WS-1965) post in Ambient protocol)

(see also Custom Server)

The tool acts as an information broker and has three main functions:

• duplicating/multiplicating the received data and post them to different destinations (up to 100)
• change the format before posting/copying: e.g. Ecowitt protocol to Ambient protocol; Ecowitt protocol to CWOP protocol, MQTT etc.
• add information to the data received from the console like sunshine hours, 10 min average wind speed etc.

for a complete feature list click here

The below picture shows examples of its features and the weather services and/or data logger programs involved

It has been tested to run on a RaspberryPi3/4 with Raspbian, Debian, Ubuntu OS, on NAS servers in a VM (virtual machine) or a container, on WSL (Windows Subsystem for Linux [Win10/11]) and others).

Download the latest stable version (0.09) (June 2025) from https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip
or the public beta version Beta 0.010 from https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip

to use the FOSHKplugin/MQTT solution with HomeAssistant, look up the FOSHKplugin documentation: HA MQTT integration via FOSHKplugin (follow the link and search for “Further processing of data from FOSHKplugin in Home Assistant”).

Installation:
On a Raspberry Pi or a NAS server with a Linux derivate installation, the installation is pretty simple: in the following installation example it is assumed that FOSHKplugin is installed in the /opt/FOSHKplugin directory
the installation script will download all missing dependencies needed for FOSHKplugin to run, mainly Python libraries.
the commands below also assume that you are not logged into your Linux installation as the user root. Hence the sudo in front of the commands - when you logged in as user root, sudo is not necessary

# create a local directory
sudo mkdir /opt/FOSHKplugin
#
# change into the created directory
cd /opt/FOSHKplugin
#
# get the current version of the plugin via wget
sudo wget -N http://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip
# or use a local zip-file
#
# unpack ZIP-File  -  you may need to install the unzip program first: sudo apt-get install unzip
sudo unzip generic-FOSHKplugin.zip
#
# Allow execute right for generic-FOSHKplugin-install.sh (this script)
sudo chmod u+x generic-FOSHKplugin-install.sh
#
# Run generic-FOSHKplugin-install.sh (this script)
sudo ./generic-FOSHKplugin-install.sh -install 

during installation the installation script queries from the user all data needed for FOSHKplugin to work and enters them into the foshkplugin.conf configuration file. You then only have to enter data to the FORWARD section (target URL, protocol format, mapping if needed …). For each forward (0-99) a separate section exists/has to be created,

upgrading to a newer version (or Beta version) maintaining the existing configuration

/opt/FOSHKplugin$  sudo ./generic-FOSHKplugin-install.sh --upgrade

An installation under WSL (Windows Subsystem for Linux) needs some more configuration resulting from the way a Linux system of your choice, default is an Ubuntu installation, is installed in a virtual machine under Windows 10/11 using the Hyper-V hypervisor. The virtual machine resides in a different network subnet in the 172.16.0.0/12 range (i.e. 172.16.0.0 - 172.31.255.255) and the local area network where the Windows computer is in usually has a different range (10.0.0.0/8 or 192.168.0.0/16). For the posts of an Ecowitt console to reach FOSHKplugin in the 172.16.0.0/12 network, forwarding rules and firewall rules need to be applied to the Windows host (computer, PC).
When the Windows computer runs 24/7, there are no issues except when usually once a month an operation system upgrade occurs. Because, when the Windows computer restarts or goes into hibernation, the WSL VM IP address changes. This has then either to be manually corrected or a PowerShell script needs to be installed which deletes the old port forwards and firewall rules and creates the matching new ones.

create the network interconnection and firewall rules for the Windows firewall

# to be executed with elevated rights (administrator rights)
# assuming that the FOSHKplugin default port 8080 is used and that the Ecowitt console posts to this port
# if the port is different, the different port number has to be used instead

"netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=172.xxx.xxx.xxx" 
# (172.xx.xxx.xxx is the WSL-IP-address - command to be executed without "")

# the command "ip addr| grep eth0" [without ""] executed in WSL-console shows the WSL-IP after "inet")
# example:
/opt/FOSHKplugin$ ip addr|grep eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 172.26.2.88/20 brd 172.26.15.255 scope global eth0
# the WSL-IP adress is 172.26.2.88 in this example

create the network interconnection and firewall rules for the Windows firewall

to be saved as a text file with the exten .ps1, e.g. wsl-network-refresh.ps1

$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

if( $found ){
  $remoteport = $matches[0];
} else{
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

#[Ports]

#All the ports you want to forward separated by comma
# if the port the Ecowitt console posts to is 8080, 8080 has to added to the $ports= command
$ports=@(80,111,443,2049, 10000,3000,5000);


#[Static ip]
#You can change the addr to your ip config to listen to a specific address
$addr='0.0.0.0';
$ports_a = $ports -join ",";


#Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

#adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}

central files in a FOSHKplugin installation
foshkplugin.conf - contains sender data and the forwarding rules including mapping, conversion and addition instructions
raw-foshkplugin.log - contains the data received from the console
snd-foshkplugin.log - contains the data forwarded
log-foshkplugin.log - contains general operating system messages which are also written to the server syslog

————————————————————————————————————————————————————————————————

the data to be entered to make your Ecowitt (clone) console post to FOSHKplugin:

*) or an interval of your choice: 8-600 seconds
**) default port - can be changed by the user, see example (WSV+ view)

(port 8080 is the default port used by FOSHKplugin - if this port is already used by another application, you will have to change that port number - or, if you want to run more than one instance of FOSHKplugin on the same server, each instance will need its own dedicated port e.g. 8080, 8081, 8082 …)










option/parameters in foshkplugin.conf

# foshkplugin.conf - configuration file
[Config]
LOX_IP =                        # Loxone-IP or broadcast-address to send data to
LOX_PORT = 12340                # Loxone-Port - port to send data to
LB_IP =                         # Loxberry-IP
LINK_ADR =                      # use the specified IP address or a server name instead of the local IP address in links (when operating on a public server)
LBU_PORT = 12341                # Loxberry-Port - port to receive UDP-datagrams
LBH_PORT =                      # Loxberry-Port - port to receive HTML-in & out
LOX_TIME = True                 # adjust time base to 01.01.2009 (Loxone only)
USE_METRIC = True               # use metric instead of imperial values
IGNORE_EMPTY = True             # do not send -9999 or empty values
UDP_ENABLE = True               # set to False to disable UDP-sending
UDP_IGNORE =                    # comma-separated list of fields to not send via UDP
UDP_MAXLEN =                    # defines the length of a UDP datagram before deviding to several datagrams (default 2000)
UDP_STATRESEND = 0              # cycle sending of warnings via UDP in seconds
LANGUAGE = DE                   # remove or adjust to EN to use english output for wprogtxt and wnowtxt (or NL/SK/FR/ES)
AUTH_PWD =                      # if set, only incoming & outgoing http-requests containing this passphrase will be accepted
DEF_SID =                       # override the default identifier for outgoing UDP datagrams (default: FOSHKweather)
REBOOT_ENABLE = False           # enable remote reboot of weather station via UDP and http (default: False - danger!)
RESTART_ENABLE = False          # enable restarting FOSHKplugin via UDP and http (default: False - danger!)
DT_FORMAT = %d.%m.%Y %H:%M:%S   # global default for date/time format (default: %d.%m.%Y %H:%M:%S - dd.mm.yyyy hh:mm:ss)
RUN_DESC =                      # string is output as additional information in push notifications (behind the IP address) and for internal html pages help, banner, fwdstat, keyhelp, scanWS in the headline
 
[Weatherstation]
WS_IP =                         # IP-address of weather station
WS_PORT =                       # UDP-port of weather station
WS_INTERVAL = 60                # weather station will send data every n seconds (16..3600)
WS90_CONVERT = True             # automatically convert WS90 rain data keys to conventional rain sensor keys if only these WS90 rain values are present (globally)
 
[Export]
EVAL_VALUES = True              # calculate some extra values on base of current data (dew point, windchill, heatIndex, feelsliketemp, AQI, ...)
ADD_ITEMS =                     # additional fixed strings to append to every raw-data-line
ADD_DEWPT = False               # enable/disable additional dew point calculation (indoor sensor, WH31, WH45) - default: False; set to True to enable
ADD_SPREAD = False              # enable/disable additional spread calculation (indoor & outdoor sensor, WH31, WH45) - default: False; set to True to enable
ADD_VPD = False                 # enable/disable additional VPD calculation (indoor & outdoor sensor, WH31 and WH45/46 - default: False; set to True to enable
ADD_SIGNAL = False              # enable/disable signal quality acquisition on supported consoles - default: False; set to True to enable
OUT_TEMP =                      # fake the temperature-value for outdoor-sensor with value of specific indoor-sensor e.g. temp1f
OUT_HUM =                       # fake the humidity-value for outdoor-sensor with value of specific indoor-sensor e.g. humidity1
OUT_TIME = False                # exchange incoming time string with time of receiving
FIX_LIGHTNING = True            # use last known lightning data as raw data in case of empty values
UDP_MINMAX = True               # send min/max values and their occurence via UDP
URL_REPAIR = True               # automatically inserts a missing but required "http://" into the FWD_URL (default: True)
LIMIT_WINDGUST =                # limit from which windgustmph and maxdailygust are blocked for any further processing to prevent unrealistic values (e.g. WS80/WS90).
ADD_SCRIPT =                    # script to globally integrate data from third party devices - see https://foshkplugin.phantasoft.de/generic#script
 
[Forward]
FWD_ENABLE = True               # to deactivate this forward temporarily just set to False instead of deleting the URL (default: True)
FWD_CMT = This is a permanent comment field for notes on this forward
FWD_URL =                       # URL of destination
FWD_INTERVAL =                  # interval in seconds in which lines will be forwarded
FWD_IGNORE =                    # comma-separated list of fields to not forward
FWD_TYPE =                      # WU/UDP/LD/RAW/EW/RAWEW/RAWUDP/AMB/RAWAMB/WC/MT/AWEKAS/WETTERCOM/WEATHER365/REALTIMETXT/CLIENTRAWTXT/CSVFILE/TXTFILE/WETTERSEKTOR/MQTTMET/MQTTIMP/WSWIN/RAWTEXT/EWUDP/APRS/INFLUXMET/INFLUXIMP/INFLUX2MET/INFLUX2IMP/MIYO/BANNER/TAGFILE
                                # WU: WU-format
                                # UDP: UDP-String will be forwarded (default)
                                # LD: PM2.5 luftdaten.info
                                # EW: Ecowitt-format
                                # RAWEW: Ecowitt untouched
                                # RAW: as input
                                # RAWUDP: RAW via UDP
                                # AMB: Ambient-format
                                # RAWAMB: Ambient untouched
                                # WC: Weathercloud-format
                                # MT: Meteotemplate-format
                                # AWEKAS: Awekas API format
                                # WETTERCOM: wetter.com API format
                                # WEATHER365: weather365.net API format
                                # REALTIMETXT: export as realtime.txt
                                # CLIENTRAWTXT: export as clientraw.txt
                                # CSVFILE: export every single record via http(s)/POST, ftp(s) or save as a file in the filesystem
                                # TXTFILE: export every single record via http(s)/POST, ftp(s) or save as a file in the filesystem
                                # WETTERSEKTOR: Wettersektor-format
                                # MQTTMET: metric values to MQTT
                                # MQTTIMP: imperial values to MQTT
                                # WSWIN: export as WSWin compatible CSV file
                                # RAWTEXT: export every single imperial record via http(s)/POST, ftp(s) or save as a file in the filesystem
                                # EWUDP: forward (converted) incoming data to Ecowitt and forward via UDP
                                # APRS: forward in APRS protocol
                                # INFLUXMET: forward metric values to InfluxDB
                                # INFLUXIMP: forward imperial values to InfluxDB
                                # INFLUX2MET: forward metric values to InfluxDB2
                                # INFLUX2IMP: forward imperial values to InfluxDB2
                                # MIYO: forward temperature, wind and rain state to a MIYO cube (irrigation system)
                                # BANNER: save banner/sticker image with embedded weather data in the filesystem (and upload via ftp(s) or http(s)/POST)
                                # TAGFILE: user-defined output format based on tags and templates
FWD_OPTION =                    # specific forward options - e.g. to define the file with the banner definition: bannerconfig=/path/to/configfile or blacklist=False to send the additional values for spread and signal quality also in Ecowitt format for this specific forward
FWD_SID =                       # username for forward if necessary (SensorID for luftdaten.info)
FWD_PWD =                       # password for this forward if necessary
FWD_REMAP =                     # comma-separated list of fields to remap with values (from other keys): @targetkey=@sourcekey or targetkey=static value
FWD_STATUS = False              # FWD_TYPE=UDP only: if set to True attach current status on each outgoing datagram (default: False)
FWD_MQTTCYCLE = 0               # FWD_TYPE MQTTMET/MQTTIMP only: time in minutes to send the complete record while otherwise only the changes are sent (default: 0 - send everytime the complete record)
FWD_EXEC =                      # external script to be started immediately before sending, last line of the script's output is used as the new outstr for sending
FWD_WARNINT = 10                # threshold of unsuccessful forward attempts before warning
FWD_QUEUE =                     # type of file to save to if forward target can not be connected: NONE, INFLUX, AWEKAS, CMX, EW
FWD_QDIR =                      # dircetory to save the queued file(s)
 
# you additionally can use Forward-1..99
[Forward-1]
FWD_ENABLE = True               # to deactivate this forward temporarily just set to False instead of deleting the URL (default: True)
FWD_CMT = This is a permanent comment field for notes on this forward
FWD_URL =                       # URL of destination
FWD_INTERVAL =                  # interval in seconds in which lines will be forwarded
FWD_IGNORE =                    # comma-separated list of fields to not forward
FWD_TYPE =                      # WU/UDP/LD/RAW/EW/RAWEW/RAWUDP/AMB/RAWAMB/WC/MT/AWEKAS/WETTERCOM/WEATHER365/REALTIMETXT/CLIENTRAWTXT/CSVFILE/TXTFILE/WETTERSEKTOR/MQTTMET/MQTTIMP/WSWIN/RAWTEXT/EWUDP/APRS/INFLUXMET/INFLUXIMP/INFLUX2MET/INFLUX2IMP/MIYO/BANNER/TAGFILE
FWD_OPTION =                    # specific forward options - e.g. to define the file with the banner definition: bannerconfig=/path/to/configfile or blacklist=False to send the additional values for spread and signal quality also in Ecowitt format for this specific forward
FWD_SID =                       # username for forward if necessary (SensorID for luftdaten.info)
FWD_PWD =                       # password for this forward if necessary
FWD_REMAP =                     # comma-separated list of fields to remap with values (from other keys): @targetkey=@sourcekey or targetkey=static value
FWD_STATUS = False              # if set to True attach current status on each outgoing datagram if applicable (default: False)
FWD_MQTTCYCLE = 0               # FWD_TYPE MQTTMET/MQTTIMP only: time in minutes to send the complete record while otherwise only the changes are sent (default: 0 - send everytime the complete record)
FWD_EXEC =                      # external script to be started immediately before sending, last line of the script's output is used as the new outstr for sending
FWD_WARNINT = 10                # threshold of unsuccessful forward attempts before warning
FWD_QUEUE =                     # type of file to save to if forward target can not be connected: NONE, INFLUX, AWEKAS, CMX, EW
FWD_QDIR =                      # directory to save the queued file(s)
 
[CSV]
CSV_NAME =                      # file name for csv-file (always metric!)
CSV_FIELDS =                    # fields in desired order, separated with ; or ,
CSV_INTERVAL =                  # interval in seconds in which lines are written to the csv-file
CSV_DAYFILE =                   # file name for CSV-dayfile with min/max values of each last day (will be appended every day after midnight)
 
[Warning]
WSDOG_WARNING = True            # warn if weather station did not report data within n send-intervals
WSDOG_INTERVAL = 3              # checking interval for WSDOG_WARNING
WSDOG_RESTART = 0               # automatically restart FOSHKplugin on n send-intervals without data from weatherstation
SENSOR_WARNING = False          # warn on missing sensor data
SENSOR_MANDATORY = wh65batt     # a comma-separated list of all mandatory sensors
BATTERY_WARNING = True          # warn if battery level of known sensors is critical
BATTERY_WARNEXCLUDE =           # comma-separated list of keys to exclude from battery warning e.g. wh90batt
STORM_WARNING = True            # activate storm warning based on a change in air pressure
STORM_WARNDIFF = 1.75           # change of air pressure in hPa within one hour to get warning state
STORM_WARNDIFF3H = 3.75         # change of air pressure in hPa within three hours to get warning state
STORM_EXPIRE = 60               # minutes, warning will stay active since last over- and under-range indication
TSTORM_WARNING = True           # enable thunderstorm warning (needs WH57 lightning sensor)
TSTORM_WARNCOUNT= 1             # warn if more than n lightnings were detected
TSTORM_WARNDIST = 30            # warn only if lightning is closer than n km
TSTORM_EXPIRE = 15              # minutes, warning will stay active since last lightning
LEAKAGE_WARNING = False         # warn if leakage detected on any WH55
CO2_WARNING = False             # warn if co2 ppm exceeds CO2_WARNLEVEL
CO2_WARNLEVEL = 1000            # ppm threshold to trigger the co2 warning
INTVL_WARNING = False           # warn if receive interval not correspond to send interval
INTVL_PCT = 10                  # percentage value of the max. permissible exceeding of the send interval (default: 10)
REBOOT_WARNING = True           # check if current station runtime < last runtime and warn (log, pushover)
FWD_WARNING = True              # warn after n (defined by FWD_WARNINT) consecutive failed forward attempts (default: true)
FWD_WARNINT = 10                # Number of failed forward attempts until a warning occurs (default: 10)
 
[Logging]
LOG_ENABLE = True               # switch logging on and off globally (default: True)
LOG_LEVEL = ALL                 # with each log level fewer messages will be logged: ALL, INFO, WARNING, ERROR - a lower level includes the higher ones
IGNORE_LOG =                    # a comma-separated list of (sub)strings which will prevent logging a line containing these strings in standard-log
BUT_PRINT = True                # respect IGNORE_LOG also for outputs on the console (default: True)
COLOR_PRINT = True              # use colour highlighting of messages in the console window (ERROR = red, WARNING = yellow and after a warning has been cancelled = green; default: True - can be deactivated with COLOR_PRINT = False
logfile = REPLACEFOSHKPLUGINLOGDIR/log-foshkplugin.log      # default log - all start/stop/warn/error messages
rawfile = REPLACEFOSHKPLUGINLOGDIR/raw-foshkplugin.log      # logs raw messages coming from weather station only
sndfile = REPLACEFOSHKPLUGINLOGDIR/snd-foshkplugin.log      # logs outgoing messages from plugin (CSV, UDP, FWD)
 
[Update]
UPD_CHECK = True                # enable/disable firmware-update-check for weatherstation
UPD_INTERVAL = 86400            # interval in seconds of checking for firmware-updates
 
[Pushover]
PO_ENABLE = False               # enable/disable push notification via Pushover (default: False)
PO_URL =                        # keep empty to use the standard API-URL
PO_TOKEN =                      # generated API-Token from "Your Applications" at Pushover-Dashboard
PO_USER =                       # the user key shown at "Your User Key" at Pushover-Dashboard
PO_CUSTOMWARNING = True         # enable/disable user-defined push messages when values meet a definable condition (100 rules - default: True)
PO_CUSTOM = @tempc <= 2.5,Current temperature (@value°C) is equal or below 2.5°C!,False,3600
PO_CUSTOM1 = @tempf < 32,Current temperature (@value°F) is below 32°F!,False,3600
 
[Coordinates]
# coordinates are only needed for calculating cloudbase or export to Awekas-API, clientraw.txt, Weather365.net
ALT =                           # altitude in m e.g. 53
LAT =                           # latitude in dec. grad e.g. 52.668759; North of the equator has no sign. South of the equator has a - sign.
LON =                           # longitude in dec. grad e.g. 13.266274; for longitudes left of Greenwich a - sign is needed. 
 
[Sunduration]
SUN_CALC = False                # enable for better sunhours calculation (LAT, LON needed), disable to use static threshold of 120W/m²
SUN_MIN = 0                     # from this value (W/m²) calculation starts
SUN_COEF = 0.92                 # adjustment factor also depends on the location
SUNSHINE_HOLD = 0               # Hold time in seconds for value sunshine, this time continues to be output sunshine = True, even if there is no sunshine (default: 0)

example foshkplugin.conf

# foshkplugin.conf - configuration file
# example to be filled

Features: (September 2025)

• accepts http messages from a weather station (GW1000, GW1100, GW2000, HP2551, HP2560, WN19x0, DP1500, HP1000SE Pro, Sainlogic 7 in 1, ELV WS980WiFi, Eurochron EFWS 2900, Ambient Weather WS-2902, WS-2000, WS-5000, ???) locally in WU or Ecowitt protocol via network
• supports custom server on stations from Ambient Weather
• does not require cloud services or internet connection
• sends the converted metric or imperial values via UDP to any host or via broadcast in the network
• is able to feed a MQTT broker
• connection to any database system possible via telegraf
• direct support of InfluxDB
• saves the converted or imperial data sorted and / or extracted as CSV
• enables forwarding to up to 100 servers that are not supported by the weather station itself (e.g. Awekas, PWSWeather, Windy or Luftdaten.info, but you could also use Weather Underground (Wunderground, WU) in a different interval)
• can feed Meteotemplate, WeatherCloud, wetter.com and weather365.net
• may export incoming data to realtime.txt and clientraw.txt (CumulusMX, Weather Display)
• can serve as an Ecowitt relay (forward in Ecowitt protocol) for Personal Weather Tablet, weewx, PWS Dashboard and any other program expecting Ecowitt-data
• can forward incoming WU and Ecowitt messages via UDP - also as a broadcast - as they come in
• is able to convert between WU, Ecowitt and Ambient Weather format (within limits)
• can answer queries in WU protocol
• Integrated web server provides the last data record in http, UDP, CSV, RAW and JSON format as well as a simple website
• various watchdogs and warnings can be configured (battery, connection weather station and sensors, storm, thunderstorm, CO2-alert, leakage-alert …)
• calculates some extra data (dew point, feelslike, AQI, …)
• allows to gather specific values via http (getvalue)
• creates an import file for the automatic import of the data into WSWin weather software
• provides the Weather4Loxone plugin with the measured values from local weather station
• No additional software is required (WS View Plus only for teaching new sensors or for configuring the standard forwarding services)
• also works without Loxone / LoxBerry as a systemd service on Linux-systems (a Raspi should be powerful enough) for connecting other systems ( generic-FOSHKplugin.zip download link (public beta 0.10) )
• is free of charge

more details (e.g. forwarding options, conversion options etc.) can be found below via the link to the developers online manual FOSHKplugin manual

————————————————————————————————————————————————————————————————-

Hardware needed: a RTL2838U chip based reception device (often with a USB connector)
example: Nooelec RTL-SDR v5 Bundle - NESDR SMArt HF/VHF/UHF (100kHz-1,75GHz)
software needed: a RTL-SDR decoder for the frequency range from 400 MHz - 1 GHz, e.g. the rtl_433
example: https://github.com/merbanan/rtl_433
documentation: https://github.com/merbanan/rtl_433/blob/master/README.md

there are several options for the hardware and software - you have to choose one

SDR stands for Software Defined Radio (a software based radio receiver)
rtl_433 despite the name is a generic data receiver, mainly for the 433.92 MHz, 868 MHz (SRD), 315 MHz, 345 MHz, and 915 MHz ISM bands.
(SRD = short-range device; ISM = industrial, science, medicine; public low-energy frequency bands used by organizations of this type)

the hardware kit shown is examplary - there many are SDR receivers with RTL2838U chips available under different brand names. The rtl_433 software works with all of them. There are also different software decoder packages available which can be used for many purposes, not only for the sensors of weather stations but e.g. also for remote car keys, automated garage doors and many more things. Here the focus is on weather station sensors of the Ecowitt (clone) brands.

the Ecowitt sensors transmit at these frequencies depending on the legal situation of the country where they are used - and the respective consoles receive these signals. A SDR is sort of a console receiving these transmissions and the software (here rtl_433) decodes the protocols into human readable text.

In the example below the picture shows how the rtl_433 console interface with the decoded sensor information looks like.
Meanwhile the decoding (rtl_433 term: protocol) for all (non-IoT) Ecowitt sensors is available.
for the rtl_433 software versions running under Linux, Windows and MacOS exist

a working configuration file for the rtl_433 software is rtl_433_conf.txt
in a Linux environment it can be found in resp. is to be placed to /usr/local/etc/rtl_433/rtl_433.conf
(obviously rtl_433_conf.txt has to be renamed to rtl_433.conf)

for installation and use look up the above link - or the respective link of the rtl_433 software of your choice

an (extreme) example for the use of RTL 433 SDR with 56 WH51 soil moisture sensors combined into a HomeAssistant dashboard view below:

(photo courtesy user @RunMike at wetterstationsforum.info (German))

————————————————————————————————————————————————————————————————-

Homebridge is open-source software that lets users connect smart home devices that aren’t traditionally supported by Apple’s HomeKit to the platform. In summary, it sits in the middle of smart home devices and Apple’s HomeKit and allows device connectivity.

Homebridge is compatible with many different smart home devices but must be installed on a standalone device. An easy way to install Homebridge is using a Docker VM, which makes the overall support of Homebridge very broad.

Homebridge is designed to interact with Apple’s HomeKit, and unlike Home Assistant, it’s not designed for standalone use.

For more details on the integration of Fine Offset / Ecowitt devices into HomeKit via Homebridge see
HomeKit/Homebridge Ecowitt Integration


HomeBridge uses the Customized Server functionality making the console post its data to HomeBridge
Ambient and Ecowitt protocol are supported - the configuration is either via the awnet app (Ambient), the WS View Plus app or, if available, the local WebUI.
awnet and WSV+ examples below:

————————————————————————————————————————————————————————————————-

Meteotemplate created by Jachym Brzezina provides a template using a modular building approach.

Before you can install Meteotemplate, you have to register at https://www.meteotemplate.com, receive a download link and get access to the Meteotemplate online WiKi.

you will need a data feeding application like CumulusMX, Meteobridge, an Ecowitt console in combination with a Meteotemplate-Ecowitt plugin, FOSHKplugin etc. and a SQL database preferably installed on the same server where you install the template (a series of PHP scripts and configuration files).
the data sent to/received by the MT API can be viewed interactively.

Meteotemplate supports in principle the display of all Ecowitt sensors. If you want to archive all sensors as historical data, you may have to extend the database schema to accommodate the data which go beyond the provided data base fields. The data is archived every five minutes.

In a configuration tool you first select the high-level design of your MT landing page (separate pages can be configured for desktop and mobile devices): how many columns you want to use (combinations are possible), colour setup, headline.
The columns are then populated with so-called blocks and plugins from a block/plugin repository and will need to be adapted to your preferences.

below an example of a customized Meteotemplate with blocks and plugins positioned in three columns.
————————————————————————————————————————————————————————————————-