Table of Contents
WiKi
(update status: 22-Jan-2025 - what's new ? see WIKI changelog) - FAQs here
Fine Offset/Ecowitt weather stations,
their clones* and pertaining sensors
(* Ambient, DNT, ELV, Froggit, GARNI, Huygens, Misol, PanTech, ProTech, Steinberg, Tycon, Waldbeck, Watson …)
the purpose of this WiKi is
- to give an overview of the FineOffset/Ecowitt Weather Stations aka the Ecowitt ecosystem
- to show compatibility and expandability of consoles and sensors
- to provide information which is sometimes not easy to find in the manuals
- to provide background information which you don't find in the manuals
- to provide information about firmware: how to upgrade, latest not documented features etc.
- to provide help you may not find in this quality and extent on the resellers' Facebook user groups (provided they exist)
- provide help with potential issues and problems you may encounter with your weather station
the Wiki is kept up-to-date whenever changes or new information become available and can claim to be the best source of Fine Offset/Ecowitt weather station related information in the internet in English language - the related forum is www.wxforum.net and the
Ambient Weather and Ecowitt and other Fine Offset clones subforum or board at
https://www.wxforum.net/index.php?board=111.0
It has grown from the thread/topic
MUST READ - Fine Offset Clone Models,sensor compatibility,firmware + other info
https://www.wxforum.net/index.php?topic=40730.0
As it had grown bigger and bigger over time and difficult to work through due to the limited features of the forum software, the composer of that MUST READ thread has decided to host it inside an open source WiKi software where the information can be accessed, paged through etc. more easily. Over time more information gained in the forum and elsewhere will find entry here.
Hints and information regarding the FineOffset/Ecowitt and reseller (clone) hardware and software (firmware) have been verified with the manufacturer (FO/Ecowitt) and can be considered reliable.
Some tweaks or “hacks” might be experimental only and may change over time as they might result from deep diving and digging into the Ecowitt console and sensor firmware and their reference may have changed as these insights were not officially published by the manufacturer. Those will be marked “experimental” to distinguish them from officially confirmed information.
DISCLAIMER:
Any action taken from information available here is on your own risk. All information is provided based on best effort and good-will, collected, compiled and published in good faith and with best intentions.
The author declines all responsibility originating from wrong, misunderstood or misapplied information.
SIDE REMARK
the author of the WiKi not being a native speaker of the English language, and beyond the sometimes different use and spelling of words on both sides of the Atlantic, spelling or grammatical mistakes can occur, even a wrong use of words. The author is grateful for any hint in this respect and is happy to implement linguistic corrections once they become known to him. Feel free to send a respective PM at wxforum.net and address it to user Gyvate.
Of course, errors or incomplete descriptions of factual nature are also welcome to be conveyed.
comments can also be posted to/in:
MUST READ 2.0 - new Fine Offset (FOSHK) Weather Stations and clones WiKi
the arrow-up at the right border of the text will always bring you back up to the table of contents
(if the table of contents is “in your way”/blocks your view, you can fold it in by clicking on the little arrow top right of the ToC)
LINKS will always be shown in bold green colour
(hovering with the mouse pointer over them will show the text underlined !)
you may want to reload this page in your browser each time you visit as content may have changed or been added since your last visit (and your browser is still displaying cached data)
before you may miss it -
there is also a growing FAQ and troubleshooting section (see table of contents - chapters 22 and 24) where we will mention often met issues and their possible solutions
suggested troubleshooting approach:
- read the FAQs
- read the troubleshooting section
- read the console, sensor and application topic which you suspect to have trouble with
- if nothing works: post your issue at wxform
- if 1. - 4. do not work, send an email to support@ecowitt.com and describe your issue
(alternatively, if you purchased your station, console, sensor at Ambient or Froggit, you can also contact their support. Ambient: support@ambientweather.com, Froggit: info@hs-group.de)
in your post at wxforum.net or in your email to support@ecowitt.com please provide:
- sensor (array) and/or console model name (or app, WebUI, dashboard)
- firmware (device, WiFi, array) version
- purchased when and where
- describe symptoms, issues and what all you have already done at no avail
- share your solution and the Ecowitt support response, if any, in your post at wxforum.net
(it can help the WiKi Troubleshooting section to grow for others to benefit)
a table of acronyms (abbreviations) used in the WiKi can be found HERE
visitor and traffic statistics
interim visitor numbers - 20-Jan-2025
going-live date: 14-Mar-2024
(for a better [bigger] view open picture in a new browser tab - or click twice on the picture)
10,000 visitors reached 13-Jul-2024 (after 4.0 months)
20,000 visitors reached 27-Oct-2024 (after 7.5 months)
30,000 visitors reached 08-Jan-2025 (after 10.0 months)
Summary by Month | |||||||||
---|---|---|---|---|---|---|---|---|---|
Month | Daily Average | Monthly Totals | |||||||
Hits | Files | Pages | Visitors | Hits | Files | Pages | Visitors | Bytes | |
2024-03 | 2158 | 2046 | 102 | 42 | 60421 | 57291 | 2865 | 1170 | 12.4 GB |
2024-04 | 3461 | 3294 | 147 | 57 | 103835 | 98805 | 4407 | 1709 | 24.9 GB |
2024-05 | 6360 | 6171 | 163 | 73 | 197161 | 191294 | 5065 | 2258 | 63.1 GB |
2024-06 | 8401 | 8171 | 191 | 96 | 252040 | 245138 | 5723 | 2885 | 72 GB |
2024-07 | 10513 | 10292 | 191 | 83 | 325911 | 319056 | 5932 | 2580 | 81.6 GB |
2024-08 | 12823 | 12537 | 241 | 103 | 397504 | 388638 | 7466 | 3183 | 96 GB |
2024-09 | 13083 | 12810 | 238 | 113 | 392489 | 384298 | 7153 | 3403 | 89.9 GB |
2024-10 | 12579 | 12337 | 214 | 100 | 389939 | 382459 | 6621 | 3106 | 94.2 GB |
2024-11 | 18245 | 17930 | 292 | 148 | 529119 | 519976 | 8474 | 4280 | 112.8 GB |
2024-12 | 19381 | 18991 | 369 | 116 | 600816 | 588728 | 11453 | 3596 | 125.4 GB |
2025-01 | 32887 | 32250 | 634 | 365 | 723516 | 709509 | 13947 | 8024 | 150.6 GB |
——————————————————————————————————————————————-
Daily Access Statistics for 2025-01 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Day | Hits | Media | Pages | Visitors | Traffic | |||||
01 | 20551 | 2.84% | 20153 | 2.84% | 398 | 2.85% | 295 | 3.68% | 4.1 GB | 2.72% |
02 | 35748 | 4.94% | 35347 | 4.98% | 398 | 2.85% | 198 | 2.47% | 7 GB | 4.65% |
03 | 22538 | 3.12% | 22304 | 3.14% | 233 | 1.67% | 128 | 1.60% | 4 GB | 2.67% |
04 | 21648 | 2.99% | 21267 | 3.00% | 381 | 2.73% | 184 | 2.29% | 5.1 GB | 3.42% |
05 | 26360 | 3.64% | 25844 | 3.64% | 508 | 3.64% | 212 | 2.64% | 5.5 GB | 3.63% |
06 | 31624 | 4.37% | 31161 | 4.39% | 452 | 3.24% | 315 | 3.93% | 6.2 GB | 4.12% |
07 | 22410 | 3.10% | 22097 | 3.11% | 313 | 2.24% | 131 | 1.63% | 4.8 GB | 3.18% |
08 | 17531 | 2.42% | 17207 | 2.43% | 321 | 2.30% | 142 | 1.77% | 3.7 GB | 2.45% |
09 | 25902 | 3.58% | 25100 | 3.54% | 801 | 5.74% | 216 | 2.69% | 5.4 GB | 3.60% |
10 | 20656 | 2.85% | 20247 | 2.85% | 408 | 2.93% | 132 | 1.65% | 4.5 GB | 2.99% |
11 | 20195 | 2.79% | 19697 | 2.78% | 498 | 3.57% | 128 | 1.60% | 4.4 GB | 2.90% |
12 | 21831 | 3.02% | 21362 | 3.01% | 468 | 3.36% | 122 | 1.52% | 4.7 GB | 3.10% |
13 | 16154 | 2.23% | 15764 | 2.22% | 390 | 2.80% | 163 | 2.03% | 4.2 GB | 2.78% |
14 | 17279 | 2.39% | 16928 | 2.39% | 351 | 2.52% | 109 | 1.36% | 5 GB | 3.32% |
15 | 20357 | 2.81% | 19840 | 2.80% | 511 | 3.66% | 113 | 1.41% | 4.7 GB | 3.14% |
16 | 18365 | 2.54% | 18022 | 2.54% | 341 | 2.44% | 101 | 1.26% | 4.7 GB | 3.13% |
17 | 16295 | 2.25% | 15937 | 2.25% | 356 | 2.55% | 103 | 1.28% | 3.3 GB | 2.20% |
18 | 152721 | 21.11% | 149968 | 21.14% | 2740 | 19.65% | 1614 | 20.11% | 29.2 GB | 19.40% |
19 | 94190 | 13.02% | 92157 | 12.99% | 2031 | 14.56% | 1022 | 12.74% | 18.7 GB | 12.42% |
20 | 48908 | 6.76% | 47830 | 6.74% | 1075 | 7.71% | 452 | 5.63% | 9.7 GB | 6.47% |
21 | 37609 | 5.20% | 36809 | 5.19% | 797 | 5.71% | 2042 | 25.45% | 9 GB | 5.99% |
22 | 14644 | 2.02% | 14468 | 2.04% | 176 | 1.26% | 102 | 1.27% | 2.6 GB | 1.71% |
——————————————————————————————————————————————-
Overview and introduction
(update status: 22-Jan-2025 - what's new ? see WIKI changelog) - FAQs here
There are several companies selling Fine Offset hardware. We informally call them Fine Offset clones.
Fine Offset (earlier: Fine Offset Electronics Co., Ltd.,FCC Wireless Applications, Hong Kong, China; registered 2006 - nowadays named: Shenzhen Fine Offset Electronics Co., Ltd.) doesn't directly sell any hardware to the end customer under their company name. Their retail branch (B2C)* runs under the brand name Ecowitt. There are reseller companies in all parts of the world which acquire bulk hardware from Fine Offset (B2B)* and usually put their branding on the hardware and often use different model numbers and even different part numbers for the same stuff. There can be several differences though to keep in mind. For example one reseller brand may only provide a certain frequency (RF) for their sensors and consoles, which means that mixing brands would not work when the frequencies are different. Even when the frequencies match, sometimes the parts can possibly not be compatible because of firmware differences by each company (see Ambient and Garni). The purpose of this WiKi is to explain these differences and help users to better customize their stations and provide more options. Do also keep in mind that some reseller companies sell Fine Offset hardware along with other hardware that comes from yet different manufacturers and consoles and sensors not listed here are most likely that and therefore not compatible with the Fine Offset hardware.
* B2C: business to customer - B2B: business to business
Only the consoles and sensors shown and mentioned here are compatible amongst each other, provided they transmit/receive at the same frequency (RF) and their firmware is fit for processing. The matrix below will show the compatibility. More details can be found in the respective console/sensor sections.
Shenzhen Fine Offset Electronics Co., Ltd. are the manufacturer of the weather stations described and discussed here. They are the factory (target group: resellers/business customers e.g. Ambient, Froggit, Misol, …) whereas Ecowitt are FineOffset's private customer outlet/front (target group: retail, private users) both being involved in research and product development. While the resellers sell usually only a (sometimes very small) portion of the FO portfolio, Ecowitt sells the whole range of weather stations and sensors manufactured by Fine Offset to the end customer. Selling certain models to certain countries may be restricted due to a special contract (e.g. the Ecowitt HP2553 station is not sold by Ecowitt to a USA address due to a special agreement with Ambient).
Ecowitt show their B2C portfolio of weather stations and sensors at https://www.ecowitt.com
Ecowitt sell their equipment via their own web shop https://shop.ecowitt.com and via other distribution channels like Amazon (DE, IT, UK, US, CA, AU) or AliExpress in a dedicated Ecowitt store.
(the Fine Offset website https://www.foshk.com is for demonstration and business customer information purposes only.)
BTW - you can have multiple consoles (with or without display) - with the same or with different sensors
The latest consoles, the GW1100/GW1200/GW2000 (matchbox size/11 cm soucer size), are low-cost but very powerful display-less consoles
Ecowitt weather stations and available add-on sensors show an amazing product bandwidth from a simple (1-3) thermometer only display console via 5,6,7-in-1 sensor arrays up to a host of different single or combo-sensors which can be added to the respective weather station kit. Some stations are not expandable and others expandable “to the brim”.
Recently intelligent sensors/IoT devices have been added.
All that (in spite of the usual low-cost/low-quality image of China-based hardware) in high quality with affordable pricing and excellent customer support. This is documented in many experience reports/posts in wxforum.net and not just cheap advertisement.
This WiKi describes the whole bandwidth including related topics
popular Fine Offset / Ecowitt and reseller related forums and discussion groups
name | provider | link | area | remarks |
Ambient Weather and Ecowitt and other Fine Offset clones | wxforum.net | https://www.wxforum.net/index.php?board=111.0 | international forum | free registration for viewing pictures required |
Wetterstationsforum | wetterstationsforum.info | forum: https://www.wetterstationsforum.info WiKi: https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen | German language (D, A, CH) | free registration required |
Ecowitt Family | https://www.facebook.com/groups/1362548130517956 | worldwide | registration required | |
Ecowitt Wittboy & WS90 User & Help Group | https://www.facebook.com/groups/1184055165466328 | worldwide | public, no registration required | |
Ambient Weather Network User's Group | https://www.facebook.com/groups/ambientweathernetwork | mainly USA | registration required | |
ecowittweather | discord | https://discord.com/channels/1075675015707639838/1075724793732661269 | international | official discord Ecowitt discussion groups / registration required |
————————————————————————————————————————————————————————————————-
1. (WiFi) console and sensor packages (Weather "stations"): a PWS
want to buy a new weather station from the Fine Offset/Ecowitt “universe” ?
looking for some decision help ?
see next chapter 1a what station to buy
A Personal Weather Station or Private Weather Station (PWS) - as opposite to an official weather station run by a governmental institution or agency under the rules of the World Meteorological Organisation (WMO) - is an appliance which collects weather data of your microclimate at the place where you install it.
you can try to set up your PWS close to the recommendations of the WMO, but there is no obligation, and there may be good reasons for you to know your microclimate data rather than standardised weather data.
The goals of official weather institutions for using their weather stations and those of private persons owning their PWS are mostly quite different. Still, both can benefit from each other's experience and data.
When you have a greenhouse, it is probably more important for you to know the actual data in there (temperature, humiditdy soil moisture …) rather than standardised values which do not reflect your local reality. Or, when you want to chill out on your balcony or in your garden, you may rather want to know the actual temperature there independent of whether this matches the WMO requirements or not.
When you have set up your outdoor sensors (a sensor array = many sensors-in-one-assembly or single sensors), you can see the actual values either on a console screen, in a Smartphone/tablet app or in a Webbrowser, locally or from a website where your console sends (posts) its data in regular intervals.
a weather station basically consists of two elements: sensors or sensor groups (sensor arrays) which read and transmit the weather data and consoles which receive and process the sensor data - a console can have a screen for display or can be displayless. In the latter case it is often called a gateway.
Prerequisite is that sender and receiver work at the same radio frequency and that the firmware of the console allows for the processing of the sensors (not all consoles can process all sensors). (see also Compatibility Matrix)
Usually a modern console can be connected to a local network* (via WLAN [“WiFi”] or LAN) and send (post) its data there - and then via an internet router into the internet e.g. to a Weather Service website like ecowitt.net or Weather Underground or to a personal website.
(Almost) all Fine Offset / Ecowitt (clone) consoles use 2.4 GHz WLAN only** to connect to the local network or for the user to connect directly to the console independent of the local network via an access point (AP)/hotspot, inbuilt WLAN.
*) this process is also called “pairing” or “network provisioning” (see console->router pairing process)
** the GW2000/GW3000 consoles/gateways and the Ambient ObserverIP2/IP3 have also an Ethernet LAN port
Sensors and consoles can be compared to a radio station (sensor) and a radio receiver (console). Therefore, many consoles can receive the same sensor(s) in parallel.
The sensors transmit their data in a RF (radio frequency) band. The transmission of data at certain frequencies is regulated by national laws and international agreements.
Private Weather stations (PWS) are considered to be short range devices (SRD) and for them in different areas (continents, countries) certain frequency bands are allowed to be used as long as the range (transmission distance) is not too big. This is defined by the transmission energy of the device. The sometimes expressed wish by users to increase sensor transmission energy in order to increase their range finds its limits in these regulations.
Private Weather Stations (sensors –> console) transmit in the so-called ISM / SRD bands (ISM: industry, science and medicine) which are 433 MHz (worldwide), 868 MHz (Europe), 915 MHz (Americas, Oceania), 920 MHz (Japan, Korea)
With many PWS you find more than one sensor combined inside one physical housing unit - a so-called sensor array. Sensor arrays have advantages and disadvantages over single sensors. Their main advantage is their compactness and the ease in maintenance. The disadvantage is that having all sensors in one place is not optimal for the quality of the sensor reading results of certain observations (=weather data) and therefore a compromise.
Ideally, as per recommendation of the WMO (World Metereological Organization), the main readings of outdoor temperature and humidity, rainfall and wind should be taken at different heights:
- temperature 2 m / ~ 6.6 feet above ground
- rainfall 1 m (0-500 m a.s.l.) - 1.5 m (above 500 m a.s.l.*) / ~3.3 - 5 feet above ground
- wind 10 m - 15 m / ~33 - 49 feet above ground
in an obstacle-free environment.
*) above sea level
For a personal weather station (PWS) it may not be so highly important to abide by these recommendations. The use of single sensors will make you of course more flexible - also regarding your own micro climate.
in short:
Definition: station = console + sensors/sensor array (a gateway in the context of this WiKi is a displayless console)
shortcut to
below the actual weather stations sold as packages (models, kits) by Ecowitt (November 2024):
Ecowitt GW1x01: GW1x00 console + WS69 (I) 7-in-1 sensor array
Ecowitt GW1x02: GW1x00 console + WS68 5-in-1 sensor array + WH40 rain gauge + WH32 outdoor Temp&Hum sensor
Ecowitt GW1x03: GW1x00 console + WS80 6-in-1 sensor array (ultrasonic anemometer) + WH40 rain gauge
(x=0,1)
Ecowitt GW1108: GW1100 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt GW1208: GW1200 console + WFC01 IoT Wittflow intelligent water valve
Ecowitt GW1209: GW1200 console + WFC01 IoT WittSwitch intelligent switch
Ecowitt GW2001: GW2000 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt GW2002: GW2000 console + WS69 7-in-1 sensor array
Ecowitt HP3500B: HP3500 TFT console + WH65 (I) 7-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B)
Ecowitt HP3501: HP3500 TFT console + WS68 5-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B) + WH32 outdoor temperature/humidity sensor + WH40 rain gauge
Ecowitt WS2320E: WS2320E LED console + WH65 (I) 7-in-1 sensor array
Ecowitt HP2551: HP2551 console + WS69 (I) 7-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B)
Ecowitt HP2552: HP2551 console + WS68 5-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B/WN32P) + WH32 outdoor temperature sensor + WH40 rain gauge)
Ecowitt HP2553: HP2551 console + WS80 6-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B) + WH40 rain gauge
Ecowitt HP2564 : HP2560 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt WN1820: WN1820 console + WH31 multi-channel extra temperature/humidity sensor
Ecowitt WN1821: WN1821 console with inbuilt CO2 sensor + WH31 multi-channel extra temperature/humidity sensor
Ecowitt WN1921: WN1920 console + WN67 5-in-1 sensor array (classic anemometer + rain + outdoor T/RH sensor) (no solar ! - no solar panel)
Ecowitt WN1981: WN1980 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt WN1982: WN1980 console + WS85 3-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Essence3” + WN32 outdoor (no solar !)
Ecowitt WS3800: WS3880 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt WS3801: WS3800 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt WS3802: WS3800 console + WS85 3-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) + WH32 outdoor (no solar !)
Ecowitt WS3901: WS3900 console + WS90 7-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) “Wittboy”
Ecowitt WS3902: WS3900 console + WS85 3-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) + WH32 outdoor (no solar !)
Ecowitt WS3912: WS3910 console with inbuilt CO2 sensor + WS85 3-in-1 sensor array (ultrasonic anemometer + haptic/piezo rain sensor) + WH32 outdoor (no solar !)
Ecowitt WS6211 (WittField Combo): WS6210 console + WS69 7-in-1 sensor array
Ecowitt WS6212 (WittField Suite): WS6210 console + WS68 4-in-1 sensor array + WH40 rain gauge + WN32 outdoor T/RH sensor
*) this has changed meanwhile (mid-2022)
for the new hardware revision sensor array models (WH65/WS69/WS80/WS90) with exposition to salt particles in the air (e.g. near seaside or salt lakes) Ecowitt have developed a specially protected exchangeable outdoor T/RH sensor - this applies only to models with pluggable T/RH sensors (–> Sensors and Accessories)
beyond these sets/packages/kits Ecowitt also sell the single components (sensors, consoles) so you can compose your own console/sensor “fleet”
if you want to have solar data along with a WS85, you have two options:
1. get yourself a WS68 solar/wind array
(the WS68 wind data won't be shown together with a WS85, but can be viewed with a second console/gateway)
2. get yourself (or reuse if you already have one) a WS69
(only its solar and traditional rain data will be available when a WN32 outdoor is registered to the console/gateway)
some recent Fine Offset / Ecowitt stations see below (November 2024)
—————- WN1982 ———————————— WittField Combo
Froggit is a weather station reseller brand of HS Group GmbH & Co. KG based in Köln (Cologne), Germany, which sells 868 MHz frequency stations and sensors across continental Europe. They do not sell the full range of Ecowitt consoles (e.g. no WN1900, no WS3800) nor their IoT devices (status July 2024) and do not ship anymore into the UK after Brexit. However, they sell the widest range of Fine Offset models and sensors of any other reseller.
Froggit stations have a different naming system (see matrix) but are functionally the same as Ecowitt stations.
The only visible difference is the brand name “Froggit”.
Froggit WH3000SE PRO WiFi: WH3000SE console (WS2910 console) + WS65 (Y) 7-in-1 sensor array
Froggit WH4000SE: WH4000SE console (WH2320E console) + WS69 (I) 7-in-1 sensor array (+ local PC console software and database)
Froggit DP1500 PRO (1): DP1500 console (GW1100) + DP50 (WH31) + WH65 (Y) 7-in-1 sensor array [called WH3000SE outdoor array]
Froggit DP1500 PRO (2): DP1500 console (GW1100) + DP40 (WH32) + DP80(WH40) + DP300 (WS68) 5-in-1 sensor array [called Froggit DP1500 PRO WiFi Gateway Single Sensor Weather Station]
Froggit HP1000SE Pro: HP1000SE Pro console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WH65/WS69 (Y) 7-in-1 outdoor sensor array
Froggit WH2600 PRO: WH2600 PRO WiFi Gateway (WH2650/WH2680) + indoor T&H&P 3-in-1 sensor (WH32B) + WH65/WS69 (Y) 7-in-1 outdoor sensor array (removed from their web page Jul-2024)
Froggit HP1000SE Pro Single sensor: HP1000SE Pro console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS68 5-in-1 outdoor sensor array + WH32 outdoor T&H sensor + DP80 (WH40) rain gauge
Froggit HP1000SE Pro Ultrasonic: HP1000SE Pro console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS80 6-in-1 sensor array + DP80 (WH40) rain gauge
Froggit HP1000SE Pro 7-in-1 Ultra: HP1000SE Pro console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS90 (Wittboy)
Froggit HP2000 7-in-1 Ultra: HP2000 console (HP2560) + DP1100 (WS90 “Wittboy”)
Froggit DP2000 7-in-1 Ultra: DP2000 console with LAN and WLAN interface (GW2000) + DP1100 (WS90 “Wittboy”)
Froggit DP2000 Single Sensor: DP2000 console with LAN and WLAN interface (GW2000) + DP300 (WS68) + DP80 (WH40) rain gauge + WH32 outdoor T&H sensor
Froggit WH2600 Pro WiFi: WH2600Pro console (WH2650) + TH&P 3-in-1 indoor sensor (WH32B) + WH65 (Y) 7-in-1 sensor array
Froggit WH3900: WN1910/WN1920 color display console + WN67 outdoor array (no solar !!)
Froggit WH5000 7-in-1 WiFi: WS3900 color display console + WS69 outdoor array (would be a “WS3900 station”)
Froggit WH5000 7-in-1 Ultra WiFi: WS3900 color display console + WS90 outdoor array (would be a “WS3901 station”)
The Froggit HP2550 console version HP1000SE PRO comes in two variants - silver frame or black frame (Black Edition)
Froggit only sell the rebranded Ecowitt packages as full packages. Some but not all sensors/consoles can be purchased alone as spare parts
https://www.froggit.de/?cat=c38_WLAN-Wetterstationen--center-category-38.html (English language available)
(the WH6000 and WH5500 stations offered by Froggit are NOT FineOffset/Ecowitt clones and therefore not compatible with the Ecowitt ecosystem !!)
below the actual weather stations sold as packages (models, kits) by Froggit (November 2024):
———————————————————————————————————————————————————————————-
Ambient stations
Ambient LLC, Chandler, Arizona is a USA based company (, part of the Nielsen-Kellerman Company, Boothwyn, PA) which sells Fine Offset manufactured weather stations and sensors inside the United States of America, Australia (via amazon.com.au) and South America - all with 915 MHz RF - and also maintain their own internet weather service https://www.ambientweather.net or AWN which every owner of an Ambient console can use. Separate licenses are also available on request.
They even sell stations to Europe, however, without warning/informing the customer about frequency incompatibility and legal impact of running a 915 MHz short range device (SRD) in Europe. - Also take note of our warning at the end of this Ambient section regarding console/sensor compatibility.
Ambient WS-2000: WS-2000 console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WH65 (Y) 7-in-1 outdoor sensor array
Ambient WS-5000: WS-2000 console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS-5000-ARRAY (WS80) 6-in-1 sensor array + WS-5000-RAIN/5kRAIN (WH40) rain gauge
Ambient WS-5050: WS-2000 console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS-5000-ARRAY (WS80) 6-in-1 sensor array (ultrasonic) - NO (!) rain gauge
Ambient WS-4000: WS-2000 console (HP2551) + indoor T&H&P 3-in-1 sensor (WH32B) + WS-4000-ARRAY (WS90) 7-in-1 sensor array
(no anemometer heater, no external power supply !!)
Ambient WS-1900/2902: WS-1900/2902 console (WH2910) + 7-in-1 outdoor sensor array (the WS-1900 has NO WiFi module !)
Ambient WS-1938: WS-1938 console (Ecowitt WN1821) + WH31E (Ecowitt WH31)
Ambient WS-1965: WS-1965 console (Ecowitt WN1910/WN1920) + 5-in-1 outdoor array (WN67) [no solar/UV, no solar panel, battery run only]
Ambient WS-5000-IP Ultrasonic: the Weather Hub (ObserverIP 2.0 gateway) + WS-5000 ARRAY (WS80) + WS-5000 RAIN/WH40-RAIN + WH32B 3-in-1 indoor T&H&P sensor (WH32B/WH32 indoor)
Ambient WS-5000-IP3 Ultrasonic: the Weather Hub (ObserverIP 2.0 gateway new design) + WS-5000 ARRAY (WS80) + WS-5000 RAIN/WH40-RAIN + WH32B 3-in-1 indoor T&H&P sensor (WH32B/WH32 indoor)
Ambient WS-1553-IP: Weather Hub [ObserverIP 2.0 gateway new design] + WH65 (Y) 7-in-1 outdoor sensor array
FineOffset/Ecowitt names in (….)
below the actual weather stations sold as packages (models, kits) by Ambient (November 2024):
(* the WS-3000 is not a full-fledged weather station, it can only display up to 8 sensors of the WH31 temperature/humidity sensor family)
Not all weather stations sold by Ambient are FineOffset/Ecowitt clones !! - Only the above mentioned models and their sensors.
(to be kept in mind:
Ambient consoles only process and display Ambient branded sensors - Ecowitt consoles process and display sensors from all Fine Offset based brands*)
( *) the only exception so far is the proprietary [exclusively built for Ambient] WH48 or new Ambient CO2 T/RH (air quality 3-in-1 combo) sensor which cannot be read by non-Ambient consoles)
————————————————————————————————————————————————————————————————-
1 a. what station to buy ?
what station you want to buy will depend on your current and expected future needs or wishes
for pictures of the station kits mentioned here and their composition click here
questions to ask:
- what sensor data do I want to know and display ?
- where do I want to display the sensor data ?
options:
- on the console display (see also max # sensors, 2nd picture)
- on a smartphone/tablet app occasionally
- on a tablet (permanent display)
- on a Weather service web page
- on my own Weather web page on an internet website
- on a web page created by a permanently (24/7) running computer program
option | stations | remarks |
---|---|---|
1 | WS23202,3, WS29102,3, HP255x, HP256x, WN19x01,2,3, WN182x1,2,3,4, WS38011,2, WS39011,2 | 1 no solar data displayed, 2 no lightning 3 no air quality, 4 CO2 yes, PM no |
2 | all | GWxy00, WN19x0, WN182x, WS3z00 live data w/ WS View Plus; others 1-minute data with Ecowitt app; x=1,2,3 - y=0,1 - z=8,9 |
3 | all | with Android Personal Weather Tablet (PWT) app |
4 | all | all registered sensors with one minute update on ecowitt.net (also other Weather Sevices) |
5 | all | custom programming locally or on website |
6 | all | with data logging programs like CumulusMX, Meteobridge, weewx, Weather Display etc. |
special location needs with no power supply or WLAN available (using 4G mobile networks):
WS6006 (2 variants) and WS6210 (2 variants + customized)
the consoles WS3800, WS39x0, GW3000 and WS6210 can be combined with ALL sensors
for pictures of the station kits mentioned here and their composition click here
- do I want my weather station to be expandable in the future (= can I later on add other sensors ?)
depending on your answer(s) to these questions the below little tables/matrices can point you into the right direction - we will show one for the three main (re-)sellers: Ecowitt (worldwide), Ambient Weather (Americas and Australia/New Zealand), Froggit (continental Europe) under their own brand names
sensor type | available sensors | expandable | stations | IoT sensors included |
---|---|---|---|---|
basic | barometer, outdoor temperature/humidity, indoor temperature/humidity, rain, wind, (no solar, no UI) | yes | WN1900 | no |
basic plus | barometer, outdoor temperature/humidity, indoor temperature/humidity, rain, wind, solar, UV | no | WH2320, WH2910 | no |
extended | basic plus, extra T/RH, user temperature, Soil Moisture, Leaf Wetness, Lightning, air quality | yes | GW1x01, GW1x02, GW1x03, GW2001, WN1981, 2), WN1920 2), WS3801 | GW1200 yes, GW2000 yes, GW3000 yes, WN182x 2) yes, WN1980 yes, GW1100 no, WS3800 yes, WS39x0 yes |
special selection | basic, extra T/RH, user temperature, Soil Moisture, Leaf Wetness, air quality | yes 2) | WN182x, | yes |
2) no solar, no lightning, no rain, no pressure (WN1821 with inbuilt CO2)
T/RH: temperature/relative humidity
for pictures of the station kits mentioned here and their composition click here
another way to define station compositions or stations plus add-on sensors is via the outdoor arrays
1) not expandable
2) no IoT
3)) with tipping spoon
4) haptic rain sensor with piezo mechanism
IoT (Internet of Things) - enabled for automation devices WFC01 and AC1100
remember that you can always combine consoles/gateways with sensors of your choice - you are NOT bound to the station kits (not with Ecowitt; resellers, however, may only sell kits or only a limited choice of single consoles/gateways)
2. consoles and sensor (compatibility) matrix
clicking on the pictures below two times will magnify them in the browser - if you cannot scroll, open the image in a new browser tab
There are two more important tables available:
1. how many sensors of the same type can be connected to one console (see max # sensors)
2. which sensor readings can be displayed on which console screen, which in the Ecowitt cloud (www.ecowitt.net) only, which ones in the Ecowitt app from the internet, and which ones inside the local network via the WS View Plus app and in a webbrowser user interface (WebUI) (see max # sensors, 2nd picture)
T&H&P = Temperature, Humidity, Pressure (or Thermometer-Barometer-Hygrometer in Ambient terms)
(I) - I-shape
(Y) - Y-shape, osprey
REMARKS:
General:
sensor frequencies used/allowed for Personal Weather Stations (PWS) in different areas of the globe:
Americas (North/South) - 915 MHz
Europe - 433 MHz or 868 MHz
Asia and Oceania (Australia/New Zealand) - 433 MHz (or 915 MHz)
Japan, Malaysia, Singapore & South Korea - 433 MHz or 920 MHz
(want more detail ? see https://www.analog.com/en/analog-dialogue/articles/wireless-short-range-devices.html)
a country specific list published by Ecowitt: https://osswww.ecowitt.net/support/recommended_frequency_V1.3.pdf
In general a console works (receives RF signals) at a (one !) dedicated frequency (433, 868, 915 or 920 MHz) - hence it can only receive the signals of sensors which transmit at the same frequency.
More than one console can receive the signal of a particular sensor in parallel, provided it operates at the same radio frequency and the firmware allows for the sensor reception. (e.g. a GW1000, a HP2550 and a WH2320E can all together in parallel receive the signals of one and the same WH65 sensor array. If it were the WH57 lightning sensor, a GW1000 and a HP2550 could both receive and process its signal, however, the WH2320E could not as its firmware doesn't allow for that).
Just keep in mind that sensors are (like) radio stations and consoles are (like) radio receivers.
Multiple receivers can receive the same radio station on the same frequency as long as they are in reception range.
Ambient consoles don't display nor process Ecowitt sensors, whereas Ecowitt consoles are compatible with Ambient sensors (provided they run on the same frequency [915 MHz] and are Fine Offset clones). Only Ambient consoles can post weather data to AmbientWeather.net and not to Ecowitt.net and vice versa.
Exception: the Ecowitt WH32 outdoor T/RH sensor (Ambient depreciated their WH32E version) can be received by the WS-2000/WS-4000/WS-5000 consoles.
Footnotes: (from the matrix)
a: Ecowitt (Shenzhen, China) sell 433, 868, 920 and 915 MHz sensors/consoles (www.ecowitt.com); Ecowitt don't sell all their sensors in/to the U.S. (restricted due to Ambient contract with Fine Offset§), Ecowitt sell some models/parts in the U.S. via Amazon and to the rest of the world directly or via Amazon in Canada, Australia, Germany, UK …
b: Froggit (Germany, Europe) sell only 868 MHz sensors/consoles directly (www.froggit.de), via Amazon (D, UK - no more after Brexit) or eBay; WeatherSpare (UK) offer sales and support for Ecowitt products (www.weatherspares.co.uk)
c: Ambient Weather (U.S.A.) sell 915 MHz sensors/consoles only (www.ambientweather.com). Ambient consoles are not compatible with Ecowitt sensors due to different console firmware; Ecowitt 915 MHz consoles can read Ambient sensors of the same frequency (915 MHz)
d: other brands (list may not be complete) are: ChiliTec, DNT, ELV, GARNI, Misol, PanTech, Renkforce, Sainlogic, Steinberg Systems, Ventus, Waldbeck, Watson …etc. - however not all of their weather stations offered are Fine Offset clones
1: HP3501/3500 looks like the Ambient WS-3000 console but is totally different. The Ambient WS-3000 is running different firmware and only works with Temp/hum sensors and is not intended to be a complete weather station. Needs firmware > 1.6.2 for extra sensors.
2: here is a non-WiFi version of this console sold by some resellers like Ambient, model WS-1900. It looks identical but costs less and makes for an excellent 2nd display.
3: functionality-wise same as GW1000, needs/comes with an extra T&H&P sensor and has a 5V barrel connector (the Renkforce WH2600 is the legacy LAN model, not the new WiFi model, see also footnote 6)
4: e.g. Meteobridge [Pro, RasPi], Weather-Display, CumulusMX, WeeWX, GW1000live app, PersonalWeatherTablet (PWT) app (Android), GW1100 Windows app …
5: new hardware revisions (T/RH sensor pluggable with bluish end) of the WS80 can be fully externally powered like a WS90
6: not the same as WH2600 LAN or Ambient ObserverIP (WS-1400IP, WS-1550-IP); the WH2650 is a Fine Offset model, not part of the Ecowitt portfolio - however you can get it as WH2600Pro WiFi from Froggit or e.g. under the Waldbeck Halley/Steinberg SBS-WS-600 brands from www.amazon.de or www.expondo.de (868 Mhz only) as a Weather station set ([displayless] console + T&H&P sensor + WH65 osprey 7-in-1 sensor array).
7: the predecessor model of the WH32 is the WH26 which is no longer built. The WH32 comes in two versions:WH32 and WH32-EP (extra precision). The WH32-EP has an external probe.
see also Ch.13 sensor hierarchy Sensor hierarchy
The GW1000/WH2650/HP2550 consoles allow selective activation or deactivation of sensors. Per console there can be only one WH32 sensor active (either WH32 or WH2-EP). If it is active in the console, it overwrites all other outdoor temperature sensors which are active for the console. If you wanted e.g. to get the outdoor temperature sensor data of a WH65, a WS80 and a WH32 altogether, you would need to deploy three consoles (i.e. consoles from the GW1000/WH2650/HP2550 models).
A similar situation exists with the wind sensor data from WH65/WS69, WS68, WS80 and WS90 running in parallel - the consoles prefer WS90 over WS80 data over WS68 over WH65/WH69 sensor array data. You want both (all four), you need two (four) consoles with selective activation/deactivation of WH65, WS68, WS80 and WS90.
8: the whole number of indoor and outdoor PM2.5 sensors (WH41 and WH43) must not exceed four (4) devices (per console). You can have more than four such sensors, but they will then need to be distributed over more than one console. The same applies to the WH55 water leakage sensor.
9: the whole number of WH31 and WN30 extra sensors (WH31 and WH31-EP) must not exceed eight (8 ) devices (per console).
WH31-EP sensors come sometimes labeled WN37xS (Ecowitt internal name) - they are still WH31-EP sensors. x=A,B,C (07-Jul-2021)
10: the WS6006 is a display-less console and a WH65/WH69E array with the possibility to add two extra sensors. Target area is agriculture. The current model uses mobile networks with 3G (UMTS), 4G (LTE) standards. The predecessor didn't have extra sensors and ran on 2G / GPRS. The still to-be-released WL6006 will run on LoRa (Long Range) technology. Number and type of extra sensors still to be determined. Since firmware 1.1.30 and PC software 1.6.9 one WN34 and one WN35 sensor can be processed additionally. Since firmware 1.1.32 and PC software 1.7.1 a WS80 ultrasonic sensor array and a WH40 rain gauge can be used instead of a WS69 outdoor array.
11: Weather Networks - WU=Weather Underground (www.wunderground.com), E=Ecowitt (www.ecowitt.net), WC=WeatherCloud (www.weathercloud.net), WOW=MetOffice WeatherObservationsWebsite (wow.metoffice.gov.uk), A=Ambient Weathernet (www.ambientweather.net), C=custom server [W= WU protocol, E= Ecowitt protocol, A=Ambient protocol]
The rebranded models in the matrix (“others”) support the same Weather Networks and can use a custom server as the Ecowitt models
12: 433 MHz only
13: 915 MHz only
14: 868 MHz only
15: 868 MHz only; the Ventus W830 console displays digits only in white whereas the other brands have colored digits
16: consoles with screen - sizes (screen diagonal):
WS3800/WS39x0: 7.5“/19 cm,
HP25x0: 7”/17 cm,
HP3501: 4.3“/11 cm,
WH2910: 6”/15 cm,
WS2320: 7.1“/18 cm,
WN19x0: 4.9”/12.5 cm (portrait)
(the WS2320/WH2320E/WH4000SE console has a 4:3 LxW ratio, the other console screens have a 16:9 LxW ratio)
display-less console sizes (LengthxWidthxHeight):
GW1000/GW1100/GW1200: 2.3 x 1.2 x 0.4“ / 6 x 3 x 1 cm,
WH2650: 3 x 2.1 x 2.2” / 7.7 x 5.5 x 5.7 cm (height including antenna),
WS6006: ~4 x 2 x 0.6“ / ~10 x 5 x 1.5 cm
17: sold by Ambient ( 915 MHz) and Froggit (868 MHz), and since 30-Apr-2021 also by Ecowitt (433, 868, 915 MHz); this sensor is part of the WH31 multi-channel family (WH31x, WH31-EP and now also WN30). This means you can have maximum 8 sensors of WH31 multi-channel type (WH31, WH31B etc.) per console (see footnote 9); remember: Ambient consoles don't display Ecowitt sensors, whereas Ecowitt consoles are compatible with Ambient sensors (provided they run on the same frequency [915 MHz, 868 MHz] and are Fine Offset clones).
18: sensor data from non-Ambient Fine Offset clone consoles which have the custom server option in Ecowitt format available (WSView app –> Device list –> Weather services –> Customized) can be received and processed by Weewx with the so-called Interceptor driver. For the GW1x00/WH2650/GW2000/WN19x0 a dedicated API driver (Ecowitt gateway driver) is available. The proprietary Ambient format is not compatible with any so far existing weewx driver (as per August 2022).
19: The Tycon ProWeather TC3000WC has a console display with black letters/numbers on greenish-grayish background, similar to the Davis consoles. The other clone models have bright yellow letters/numbers on a dark blue background.
20: The 2910C console (and clones on latest device firmware (>= 2.1.9) and WiFi firmware) can receive extra sensor data from WH31 and WH41/43 sensors and publish them on Ecowitt.net. These readings CANNOT be displayed on the console.
21: the WN1900 (not to be confused with the Ambient WS1900 ) is a “low-cost console” together with a light-weight version of the WH65 sensor array (WN67) without solar panel, solar and UV sensors and longer sensor sending intervals. It can be connected to other outdoor arrays though. The console cannot display solar/UV values even if a WH65/WS80/WS68/WS90 is connected.
The console itself has the same API as a GW1000/WH2650 but with a grey-green LED display and about palm-size (i.e. can be held in one hand). 8 WH31 multi channel temp/hum sensor recycle display on the console. Other extra sensors data (same as GW1100) is not displayed on the console (pass through to ecowitt.net only); sensor management/calibration via WS VIEW app only. It comes with a greyish/black display (WN1900) or a color display (WN1910) - it is meanwhile also sold for Ambient sensors under the name WS-1965. The successor model of the WN1910 is the WN1980 console. It has the same features as the WN1910, but no more bluetooth, now WiFi 802.11 b/g/n connectivity and a WebUI. The outdoor temperature/humidity is shown in a different color (red instead of orange) and the keys are no longer at the side but touch-sensitive areas on the display.
22: the WH32B has a no longer built predecessor model named WH25. A HP2550 or a WH2650 console should be able to get readings from it as T&H&P sensor. The WH32B indoor T/H/P sensor is not to be confused with the WH32 (without a B) outdoor T/H sensor. These are different devices and cannot replace each other.
23: the WN67 (N=no solar panel) is a light-weight WH65 with no solar radiation reading. It runs on batteries only and comes with the WN19x0 console. The sensor array which comes with FineOffset WN5300, WN5350, WN2080 is NOT a WN67. It is a WN14 and uses a different modulation method for transmitting the sensor readings. WN14 uses ASK=amplitude shift keying and the WN67 uses FSK=frequency shift keying. So they are not interchangeable and cannot be received by the consoles in our matrix. The sensor arrays of Aercus 2085 and Aercus 3085 also use ASK.
24: the WH65 comes as Y-shape and the newer WS69 arrays as I-shape arrays (as per Ecowitt engineering). The WS69 can use the BP0001 battery extension pack. Newer hardware revisions come with a “milky sticker”, a filter on the solar sensor (do not remove it !) - the predecessor of the WH65/WS69 is the WH24, the “boat” (because of its shape). It can be received by the newer consoles too, only some adjustment needs to be made in the device settings - otherwise the wind readings will be wrong as the way of measuring wind has changed in the WH65.
25: the GW1100/GW1200 can also be configured and connected to WiFi via a WebUI, not only via the WSView app - the GW1200 supports the new IoT devices
26: CumulusMX V13 (b3145) can use a console/server which posts in Ecowitt, Ambient or Wunderground protocol (e.g. custom server option) as a full or complementary station (adding sensors to main station)
27: the WS90 is an all-in-one outdoor array with a haptic rain counter and ultrasonic anemometer; it's not meant to be a replacement for the WS80 - It's part of a new station (Wittboy) with an all-in-one outdoor sensor array (WS90) and a new gateway/hub GW2000 which will become home automation etc. capable in the future. Its rain sensor can be calibrated on five tiers (https://www.wxforum.net/index.php?topic=43139.msg443726#msg443726). Its SHT40 based T/H sensor can be easily replaced by an extra precision SHT35 T/H sensor (https://shop.ecowitt.com/products/sht35-temp-hygr) - it can be fully externally powered
Since February 2023 there is also a WN90LP with Modbus/RTU RS485 interface available - no solar panel, no batteries, heater powered via 5V data cable, inbuilt pressure sensor).
28: in Europe the WH31 comes also in a special edition with a DCF77 chip (radio controlled time signal) - this is not necessary for the normal consoles (GW1x00, HP2550 etc.); it works like anormal WH31 sensor
(868 MHz) - it's sold by dnt - a WH31 can be converted into a WH32 (https://www.wxforum.net/index.php?topic=43206) - the so-called WH32F sensors (max 3) of a WH28x0 console are also WH31 family sensors with a radio time receiver. Their channels 1, 2, 3 correspond to WH31 1, 2, 7.
29: see chapter 12
30: The GW2000 console/gateway can display the rain data of both the haptic (“piezo”) rain sensor of the WS90 array and a WH40 in synoptic view (firmware 2.1.1) in its WebUI and on ecowitt.net if both are registered in the console. (https://www.wxforum.net/index.php?topic=43139.msg443769#msg443769). The GW2000 possesses a LAN and WLAN interface which can be used alternatively or in parallel.
31: the WN36 is a floating pool temperature sensor, 8 channels, the 8 channels will be shared with the WH31 family; also = Ambient WH31PF
32: via Ecowitt cloud with APP and API key
33: either via Ecowitt custom server or via WS2320E API
34: indoor T/H/P sensor already integrated in HP2561
35: the WH2682 or Ambient ObserverIP 2.0 module (Ambient Marketing name: “Weather Hub”) is a displayless console/gateway and functionally similar to an Ecowitt GW2000 console/gateway upgraded hardware which is able to receive all Ambient branded sensors (but no Ecowitt sensors due to Ambient proprietary company product policy - whereas an Ecowitt GW2000 can receive all Ecowittt (clone) sensors including Ambient sensors). The WH2682 has both an Ethernet (LAN) and WiFi (WLAN) interface and a WebUI for configuration via a web browser. If it can also be configured by an (to be updated) awnet app is not yet known. (21-Sep-2022). The old ObserverIP module (WH2600, WS-1900 - LAN only) could not receive the WS80/WS-5000 ARRAY and WH40/WS-5000-RAIN, PM2.5 and AQUIN sensors.
It needs an extra indoor T/H/P sensor (WH32) like the WH2650-WiFi or the HP2551/WS-2000/WS-5000 consoles.
36: the WN1821 has an inbuilt CO2 sensor and displays WH/WN31,34,35 and WH51 - no solar, no wind, no rain no pressure
37: WS3900: 7”/19 cm display, all sensors including IoT supported, some only via ecowitt.net or WSV+/WebUI; WS3910: w/ inbuilt CO2 sensor.
*: WN34D: extended range -55 - +120°C
#: a WH46 has additional PM1 and PM4 sensors over a WH45
%: WN51 = soil moisture sensor with ceramics covered probe; under revision; no more sold
§: Fine Offset Electronics Ltd are the manufacturer, the factory (target group: resellers/business customers e.g. Ambient, Froggit, Misol, …) whereas Ecowitt are FineOffset's private customer outlet/front (target group: retail, private users) which is also involved in research and product development.
————————————————————————————————————————————————————————————————-
2 a. brand model and sensor name translation table
brand model and sensor name translation table
console | Ecowitt | Ambient | Froggit | Garni | dnt/ELV | Misol | Conrad | Watson | others |
---|---|---|---|---|---|---|---|---|---|
WS2350 | WS2320E | — | WH4000SE | — | WS980WiFi | WS-2320 | — | — | WS-SBS-400 |
WS2910 | WS2910 | WS-2902 A-D | WH3000SE | — | Ventus W830 | WS-2900 | EFWS2900 | — | Pantech WS2900 Tesa WS2980 Sainlogic 3500 Waldbeck Huygens Jaycar IC0370, XC0370 |
HP2550 | HP2550 | WS-2000 WS-4000 WS-5000 | HP1000SE Pro | Arcus 3055 | WeatherScreen Pro | HP2550 | —- | WS8686 | PanTech 2550 WS-SBS-500 |
HP2560 | HP2560 | — | HP2000 | — | — | HP2560 | — | — | Sygonix SY-5479628 |
HP350x | HP3501 | — | — | — | — | — | — | — | — |
HP3000 | HP3000 | WS-3000 | DL5000 | — | — | HP3001 | — | — | — |
WN182x | WN1820 WN1821 | — WS-1938 | — | — | — | — WN1821 | — | — | — |
WN1900 | WN1900 | — | — | — | — | WN1900 | — | — | — |
WN1910 WN1920 | WN1910 WN1920 | WS-1965 | WN3900 | — | — | — | — | — | — |
WN1980 | WN1980 | — | — | — | — | — | — | — | — |
WS3800 | WS3800 | — | — | — | — | — | — | — | — |
WS39x0 | WS3900 WS3910 | — | WH5000 | — | — | — | — | — | — |
GW1000 | GW1000 | — | DP1500 | — | — | GW1000 | — | — | ProTech WSMG1000 |
GW1100 | GW1100 | — | DP1500 | — | — | GW1100 | — | — | — |
GW1200 | GW1200 | — | — | — | — | — | — | — | — |
GW2000 | GW2000 | — | DP2000 | — | — | GW2000 | — | — | — |
GW3000 | GW3000 | — | — | — | — | — | — | — | — |
WH2650 | WH2680 | — | WH2600 Pro | — | — | — | — | — | WS-SBS-600 Waldbeck Halley |
WH2682 | — | ObserverIP 2.0 | — | — | — | — | — | — | — |
— | — | Ambient Weather Network Hub 2.0 | — | — | — | — | — | — | — |
WS6006 | WS6006 | — | — | — | — | WS6006 | — | — | — |
WS6210 | WS6210 | — | — | — | — | — | — | — | — |
sensor | Ecowitt | Ambient | Froggit | Garni | dnt/ELV | Misol | Conrad | Watson | others |
---|---|---|---|---|---|---|---|---|---|
WH65 | — | WH65 WS2000-ARRAY | WH3000SE combo | G4INT | — | — | EC-3802394 | — | — |
WS69 | WS69 | — | WH4000SE combo | — | — | — | — | — | ProTECH WS7IN1S |
WN67 | WN67 | WS-1965-ARRAY | WH3900 combo | — | — | — | — | — | — |
WS68 | WS68 | — | DP300 | — | — | — | — | — | — |
WS80 | WS80 | WS5000-ARRAY | DP1000 | G095HA | — | WS80 | — | — | — |
WS85 | WS85 | — | — | — | — | — | — | — | — |
WS90 | WS90 | WS4000-ARRAY | DP1100 | — | — | WS90 | — | — | — |
WN30 | WN30 | WH31P | DP30 | — | — | — | — | — | — |
WH31/WN31 | WH31/WN31 | WH31E/WH31RF | DP50 | G092H WH32F | dnt000005 | WH31 / WH32Q | — | — | — |
WH31-EP | WH31-EP / WN37xS | — | — | — | — | — | — | — | — |
WH32/WN32 | WH32/WN32 (WH32EC***) | (WH32E)* | DP40 | — | — | WH32 | — | — | — |
WH32-EP | WH32-EP / WN39xS | — | — | — | — | — | — | — | — |
WH32B/WN32P | WH32B/WN32P | WH32B | no name | G090HP | — | — | — | — | — |
WN34S/WN34L | WN34S/WN34L | — | DP150/DP35 | — | — | WN34 CS/L | — | — | — |
WN35 | WN35 | WH51LW | DP10 | — | — | WN35CN | — | — | — |
WN36 | WN36 | WH31PF | — | — | — | — | — | — | — |
WH40 | WH40 | 5kRAIN | DP80 | G097R | — | WH40 | — | — | — |
WH41 | WH41 | PM25 outdoor | DP200 | G080Q | — | — | — | — | — |
WH43 | WH43 | PM25 indoor | — | — | — | — | — | — | — |
WH45 | WH45 | AQIN | DP250 | G083QC | — | WH45 | — | — | — |
WH46/WH46D | WH46/WH46D | — | — | — | — | — | — | — | — |
WH48 | — | CO2+T/RH new ** | — | — | — | — | — | — | — |
WH51/WH51L | WH51/WH51L | WH31SM | DP100 | — | — | — | — | — | — |
WH55 | WH55 | WH31LA | DP70 | — | — | — | — | — | — |
WH57 | WH57 | WH31L | DP60 | G094L | — | WH57 | — | — | — |
*) depreciated, end-of-life, replaceable by Ecowitt WN32 outdoor as T&H sensor
**) cannot be received by Ecowitt consoles
***) sometimes in the past also sold as WH32EC at 915 MHz
————————————————————————————————————————————————————————————————-
2 b. console - sensor - maximum number and display tables
If the numbers and letters below are too small, click twice on the picture to have it displayed bigger
for the Ambient, Froggit etc. names of consoles and sensors use the brand model names translation table
for the gateways (displayless consoles) the viewing is (as the name says) only possibile via a web based user interface (WebUI - inbuilt or ecowitt.net dashboard) or an app (EW, WSV+)
*: end of life
x: not applicable
1: newer hardware has web page, only weather networks and customized server
2: solar values not shown on display
3: upload only - only viewable in Ecowitt Cloud dashboard and Ecowitt app (WS View Plus app [Ecowitt dashboard])
4: 16 with future firmware update (IoT enabled consoles only)
5:
6: Ambient sensor names apply - see translation table: sensor name translation table
WLAN: 2.4 GHz WLAN
LAN: 1 Gbit Ethernet
Web: inbuilt WebUI (web user interface/webpage)
App: WS View Plus app inside the local network - Ecowitt app only when internet connection via the same local network available
the table assumes that your console / gateway is upgraded to the latest firmware
upload only: upload to your personal account (dashboard) at ecowitt.net resp. in the Ecowit app/WS View Plus app (Ecowitt dashboard)
Beware that the whole number of WFC01/AC1100 devices is limited to 16. Any combination between 0/16 and 16/0 is possible.
The GW1000 and the WH2650 are no longer contained in the above matrix.
However, they can be considered the same as a HP25x0/HP350x console regarding the number and type of possible sensors which can be connected to them. In fact, on firmware 1.7.7, they both can register all Ecowitt sensors except the IoT sensors (WFC01, AC1100).
They can even display synoptically a traditional and a piezo rain gauge in the WS View Plus app while until now (February 2024) the HP25x0/HP350x consoles can only display on their screen one of the rain gauges. A cycling is not (yet ?)implemented.
The new WS85 Rain & Wind sensor cannot be registered by a GW1000/WH2650.
Their firmware will no longer be updated to support new sensors.
Now - how to read this table ? (some people seem to have difficulties to read this table properly)
you read the table per column ! Each column tells you how many sensors of which type you can maximally connect to one and the same console/gateway
a GW2000 can connect one WS90 and one WH40 and one WN32P and one WH32 and eight WH31 etc.
with the first five lines (these are the sensor arrays = many sensors in one housing), you usually choose only one, but in special cases it can make sense to have more than one
(for example: if you have a WS85 which doesn't have a solar sensor, but want also to see the solar values, you can add one more array which provides these data e.g. a WS68 which has solar and wind data. The wind data of a WS68 when combined with a WS85 will not be shown due to the sensor hierarchy, but the solar data will.)
the next table will give you a different view - what sensors can be seen on which console display/screen
on the ecowitt.net dashboards ALL registered sensors and their battery values can be seen
————————————————————————————————————————————————————————————————-
3. consoles
let us first come to grips with the multitude of terms used in the context of consoles.
There are different words used in the manuals, forums etc. which cover a certain aspect of these devices:
(they are often used as synonyms emphasising on different functionalities which they all possess)
Basis Station, Console, Gateway, Hub.
- Basis station: the part of your weather station (console + sensor(s)) which is usually kept indoors and which processes the sensor data
- Console: a device which processes the data received from the sensors (can have a display or not)
- Gateway: a connector between networks - here between the RF (radio frequency) network of the sensors and
the WLAN or LAN allowing the data to be sent/posted into this network (e.g. internet (WAN) via the LAN) - Hub: a telecommunications device that (physically) connects network nodes in a star configuration
(this refers to the RF network: console and sensors; in the local network ([W]LAN) the console is just a device and a network switch or router is the hub)
All Ecowitt consoles have all the above mentioned functionalities - therefore, the terms are interchangeable
*) exceptions are the single sensor consoles and consoles without [W]LAN connectivity like the WH28x0 consoles
Note:
All Ecowitt consoles (exceptions as mentioned before) have an inbuilt WLAN hotspot (also called access point [AP]) which can be reached via the SSID console-nameX-WIFIxxxx (e.g. GW3000A-WIFI23AC) or EasyWeather_WIFIxxxx or EasyWeatherPro-xxxxx. (the last four or five xxxxx are the last 4 rep. 5 characters of the console MAC address). The console has the IP address 192.168.4.1 in this WLAN. When you connect to this WLAN e.g. via a Laptop or a smartphone, you can reach the console WebUI by entering http://192.168.4.1 into a web browser. Of course the hotspot needs to be activatd beforehand. Procedure see manual of the respective console.
actual Ecowitt console models (August 2024)
WS6210 WLAN + 3G/4G ———————————————————GW3000
consoles without LAN/WLAN (“WiFi”) connectivity
Note regarding all Ecowitt consoles (almost all, except WS2320E and WH2910):
the consoles have an optional switchable temperature compensation for the WH65/WS69/WS80/WS90 outdoor sensor arrays,
whose temperature sensors are located in a relatively small solar radiation shield, which is generally exposed to full sunlight.
For those interested - the correction formula currently used, which is still being worked on, is
Outdoor_Temp = Outdoor_Temp - CorrectT CorrectT = solar_rad/ (10*cp*k* sqrt(u/0.0009) solar_rad: unit in W/m2. cp: 29.3, k: 0.0984, u: gust (bigger value among 0.5m/s or gust )
Ambient consoles do not have the temperature compensation feature available
(because Ambient decided it would not be needed for their customers)
with device firmware upgrade 1.9.5 for the HP25x0 console, the algorithm was changed:
outdoor temperature compensation, changing from the average of the last eight gusts to the average wind speed over 10 minutes
it is expected that the compensation algorithm will also be changed in upcoming frimware upgrades for the other consoles which already have the temperature compensation option
————————————————————————————————————————————————————————————————-
Gateways
Gateways in this context here are displayless consoles.
They usually have all the capabilities of consoles with display except for the display. Their data can still be viewed by other means like a webbrowser, apps or a special tablet/smartphone turning the tablet into a console display (e.g. PWT).
For details see the specific consoles.
(they are called gateway as they form the gate between the RF sensor-console network and the Ethernet or WiFi based [W]LAN) - in fact almost every console is also a gateway*
*) exceptions are the single sensor consoles and consoles without [W]LAN connectivity like the WH28x0 consoles
the recently (December 2024) known and available gateways
*) end-of-life
————————————————————————————————————————————————————————————————-
GW1000 (end of life)
The Ecowitt GW1000 is a matchbox-sized (small) device that has a USB 2.0 plug for power supply. In fact, this USB plug is used exclusively for power supply - there is no data interface.
In addition, a temperature/humidity sensor for recording these values in the area of the GW1000 is attached to a cable approx. 1 metre long. A pressure sensor is installed on the mainboard.
The GW1000 serves as a console (without a screen) - however, the data can be viewed in real time (!) using the WS View (Plus*) app. A popular display option for a GW1x00 is the use of an (old, new also works) Android tablet with the help of the Android app PWT (Personal Weather Tablet) see https://www.wxforum.net/index.php?topic=39453.0 (* in order to be able to connect and calibrate the WS90 outdoor sensor from firmware 1.7.4, you must use the WS View Plus app from version 2.0.32, the old WS View app can no longer do this)
The biggest advantage of this “console” is the API capability [API = application programming interface], which is also used by the WS View Plus APP for real-time data display (Live Data). Appropriately prepared software can therefore retrieve the data from the console. In July 2021, the API was finally made available to the general public.
A more detailed description can be found in the section the local Ecowitt Gateway API The GW1000, GW1100, GW1200, GW2000, WH2650 (Froggit WH2600Pro WiFi), WN1821, WN19x0 and the new WS3800/WS39x0 consoles have this local Ecowitt Gateway API aka GW1000 API.
Otherwise (with the exception of the IoT sensors, which can only be received/processed by a GW1200, GW2000, WN1980 and WS3800/WS39x0), all sensors that are currently (February 2024) available can be processed (from firmware 1.7.0 on including the WS90).
With firmware 1.7.4, temperature compensation can be optionally switched on (Device Settings) to correct possible distortion of the measured values due to solar radiation. This applies to the WH65/WS69, WS80 and WS90 combined outdoor sensors.
This option can only be used with WS View Plus App V.2.0.32 or higher.
The GW1000 is no longer sold by Ecowitt. Only the successor models GW1100 and GW1200.
Resellers such as Misol (433 MHz) or ProTech (868 MHz) are still selling their (remaining) stocks of GW1000, Froggit as DP1500.
(according to user feedback, the DP1500s sold by Froggit are now GW1100 clones (September 2022)).
The functional differences between a GW1000 and a GW1100 are minimal, no WebUI, no support of new sensors like the WS85.
Froggit: DP1500
————————————————————————————————————————————————————————————————-
GW1100
Ecowitt now sells the GW1100 instead of the GW1000. The GW1000 is no longer available from Ecowitt. However, other resellers are still selling their remaining stocks of GW1000s, e.g. Misol (433 MHz only), ProTech (in Sweden and Norway, 868 MHz or Hadex (www.hadex.cz) in the Czech Republic) or Froggit as DP1500 This is basically the same device (same design, same CPU - ESP8266, same functions, API support), but with more memory, in which Fine Offset has packed a web interface for configuring the GW1100. This means that it is now possible to make all settings not only via the WS View mobile phone app (which still works) but also via the device's web interface. As with WS View, there is also a live data page showing the current measured values.
All functions (as well as some points of criticism) of the GW1000 are included. The date and distance of the last lightning strike (if a WH57 sensor is present) are no longer lost after a reboot. However, the highest measured wind peak of the day is. However, I (@olicat) hope that the additional memory will also be used in future to rectify the known weak points.
A GW1000 can NOT be turned into a GW1100 by a software update - it simply lacks the necessary memory.
Since September 2022, Froggit has been supplying the device under the same name as the earlier GW1000, namely DP1500.
The functionality of the GW1100 and GW2000 (apart from the additional LAN interface of the GW2000) has been identical since firmware 2.1.2 (GW1100) and 2.1.1 (GW2000) (03 March 2022). Exceptions are, as described for the GW1000, the IoT sensors (WFC01 and AC1100) - these can only be received/processed by a GW2000, a WN1980/WN1821 and WS3800/WS3900.
The firmware itself in bytes is different in size, even though as of the end of April 2022 both have firmware version 2.1.4 (or 2.1.5 at the end of June).
Since firmware 2.1.5, the GW1100 has the option of switching on solar radiation and wind-dependent temperature compensation for the WH65/WS69, WS80 and WS90 combined outdoor sensors.WS View Plus (version >= 2.0.32) must now be used as the app for live data view, configuration and calibration (WS View only works to a limited extent).Newer firmware of the GW1100 and GW2000 also allows the use of a remote indoor sensor for indoor T/RH and air pressure, the WH32B (Indoor).However, this requires hardware intervention.To do this, you have to disconnect the cable of the indoor T/RH sensor that is routed to the outside (note from Ecowitt), preferably at the soldering points on the circuit board, either using pliers or by desoldering.If the firmware does not recognise an internal T/RH sensor, it allows the registration of a WH32B (TH&P) sensor.
Since firmware 2.3.1 a separate TH&P sensor can be connected instead of the internal sensors.
This does NOT apply to a GW1000! Its firmware does not support this “switching when absent”. See also note on WH32B/WH32 indoor below.
Froggit DP1500 (since September 2022)
————————————————————————————————————————————————————————————————-
GW1200
Hardware upgrade of the GW1100, which also has sufficient computing power and memory to enable the MQTT protocol used for communication with the IoT devices/sensors (WFC001, AC1100) and the corresponding encryption. It has an Espressif ESP32 C3 SoC with a RISC-V primary processor, the successor of the ESP8266. In other words, a GW1100 with IoT capabilities. Visually, it looks like the GW1100, the colour is a dark grey. A comprehensive manual can be found at https://osswww.ecowitt.net/uploads/20231221/GW1200%20Manual.pdf
The price of the GW1200 is only marginally higher than the GW1100, which is still available However, the GW1100's years are probably numbered and it will most likely no longer be produced once stocks have been sold off. After all, there is no recognisable added value.
————————————————————————————————————————————————————————————————-
GW2000
The displayless console/gateway available together with the WS90 since 1 April 2022, which has the same and in parts (when used with a WS90 7-in-1 outdoor combination sensor) extended range of functions as the GW1100 console. Like the GW1100, the GW2000 also has a browser interface (WebUI) for display and configuration. Like the GW1x00 consoles/gateways, a temperature/humidity sensor for indoor T/H measurement is led out on a cable.*) The pressure sensor is located on the mainboard. The corresponding station is called GW2001 (“Wittboy”) and consists of the GW2000 console and the WS90 7-in-1 outdoor sensor array with a haptic (“piezo”) rain gauge. This station also has a RJ45 interface to connect the device via network cable in addition to the existing WLAN interface. A fixed (static) IP address can also be assigned for the Ethernet interface. The GW2000 can also be operated exclusively via the LAN connection. However, experience to date has shown that both interfaces (Ethernet/WLAN) should not be used at the same time, as this can (so far) lead to the web interface being blocked. (Improved after firmware updates [2.1.5], but not yet fully stabilised) The GW2001/Wittboy Station has been available in the official Ecowitt catalogue and shop since 01 April 2022. The GW2000 console alone is also offered individually like the GW1100.
The GW2000 console (gateway) (firmware 2.1.1, 03 March 2022) can also display a classic rain sensor (WH65, WH40) synoptically when using a WS90 combo sensor array with haptic (piezoelectric) rain gauge. Both in the ecowitt.net dashboard and in its WebUI (web user interface). The haptic/piezoelectric rain gauge can also be calibrated in five rain rate levels depending on the rain rate in order to take into account the different behaviour of this rain gauge at different rainfall rates (mm/h). The levels are 1. 0.00 - 4.0 mm/h, 2. 4.01 - 10.0 mm/h, 3. 10.01 - 30.0 mm/h, 4. 30.01 - 60.0 mm/h, 5. 60.01 - …. mm/h
synoptical depiction of a traditional (WH40, WS69) and haptic/piezo (WS90) rain gauge in the WebUI
The GW1100 gateway also supports this function since firmware V.2.1.2 and the same functionality was introduced with firmware 1.7.2 for GW1000/WH2650 (May 2022).
With the HP25x0 console, since device firmware 1.6.8 it has been possible to select which of the two rain sensors is shown on the main display when the WS90 and WH40 (or WH65) are active/connected at the same time. An alternating (cycling) display, as with already implemented with extra sensors, would certainly be technically possible for the HP25x0 console, but is not yet available. Rain calibration of the WS90 via the HP25x0 console has also been possible since firmware 1.8.1.
As with the GW1x00 gateways/consoles, local data display is possible, e.g. via PWT (Personal Weather Tablet) on an Android tablet (even an old one) using the custom server function (see below).
Since firmware 2.1.5, the GW2000 has the option of switching on solar radiation and wind-dependent temperature compensation for the WH65/WS69, WS80 and WS90 combined outdoor sensors. The WS View Plus app (>= 2.0.32) must be used as the display (and configuration) app.
The GW2000 firmware has made a version jump from 2.2.5 to 3.0.4. The latter now also supports the WFC01 IoT sensor (see below)
An ESP32 CPU is installed in the GW2000.
*) the newer firmware (2.2.4) of the GW1100 and GW2000 also allows the use of a remote indoor sensor for indoor T/RH and air pressure, the WH32B (Indoor). However, this requires hardware intervention. To do this, you have to disconnect the cable of the indoor T/RH sensor that is routed to the outside (note from Ecowitt), preferably at the soldering points on the circuit board, either using pliers or by desoldering. If the firmware does not recognise an internal T/RH sensor, it allows the registration of a WH32B (TH&P) sensor. (see also the note on WH32B/WH32 indoor below).
Since GW2000 firmware 3.1.1, an alternative separate WH32B (indoor) T/H/P sensor can also be selected on the sensor IDs page of WS View Plus or the WebUI without the above hardware intervention.
Froggit have been selling the GW2000 as DP2000 since January 2023.
the reverse side of the GW2000 and wall-mount option
The inner life of a GW2000
————————————————————————————————————————————————————————————————-
GW3000
this gateway, the likely successor of the GW2000, has come out of the prototyping phase.
it's available for purchase since 05-Dec-2024
in addition to the GW2000 capabilities it will have a microSD slot where current data can be saved on.
The SD card will be accessible via its WebUI or via the http API and the saved data can be downloaded via the network.
Connectivity: WLAN 2.4 GHz and LAN (Ethernet) interface. All existing sensors and IoT devices supported.
it will also be wall mountable. The colour of the final product will be beige. Something between the colour on the right photo and the part description farther down.
the colours on the other pictures are from prototypes.
As per the latest news (September 2024) it will come with a detachable coax-type external RF antenna which can be replaced by the user with a different antenna model (longer cable for longer distance of antenna location, higher antenna gain etc.)
(the WebUI for the SD card looks exactly the same for the GW3000 as for the WS6210 - only the WS6210 YYYYMMZ.CSV file contains two extra battery related values)
The GW3000 comes with three LED lamps (left to right)
- RF reception
- network activity
- SD card status and activity
on the backside there are four connectors/holes available
(from left to right)
- LAN/Ethernet socket
- power socket (USB-C)
- SD card socket
- reset button (above the SD card port)
the USB-C port is for power supply only - no data connection - it's compliant with the new EU regulations for a unified charging/power connectors for electronic devices.
GW3000 manual
the structure, headers, data sequence and naming convention of the data storage CSV files (GW3000, WS6210) are:
(structure and name change logic is different from the SD card handling of the HP25x0 data)
there are two files with the naming YYYYMMZ.CSV and YYYYMMAllSensors_Z.CSV
YYYY=year e.g. 2024 MM=month e.g. 09 (September) and Z=A, B, C, ….
whenever a unit (like m/s –> km/h, °F –> °C etc.) is changed, a new set of files is created and the letter Z is added up - the same applies when fields and headers are added (or removed, the latter unlikely to happen) or their sequence changed
(A –> B –> C –> D …. etc.)
e.g. when a unit change has taken place two times, there will be 6 files (in number):
(unless they have been deleted by the user in between)
YYYYMMA.CSV, YYYYMMB.CSV, YYYYMMC.CSV and YYYYMMAllSensors_A.CSV, YYYYMMAllSensors_B.CSV, YYYYMMAllSensors_C.CSV
between unit changes the letter will be kept and only year and month change every month (the year only after month 12 [December])
e.g.
- 202404A.CSV
- 202404AllSensors_A.CSV
- 202404B.CSV
- 202404AllSensors_B.CSV
- 202404C.CSV
- 202404AllSensors_C.CSV
- 202405C.CSV
- 202406AllSensors_C.CSV
- 202406C.CSV
- 202406AllSensors_C.CSV
the YYYYMMZ.CSV files contain only the basic sensor data: outdoor/indoor T/RH, wind, pressure, solar, UV, rain
(a WS6210 has in addition the battery voltage and the external power supply voltage)
there is an entry for all possible sensors, registered or not
if a sensor doesn't exist or an existing one doesn't provide a value, “–” will be put.
example
202409A.CSV
Time,Indoor Temperature(℃),Indoor Humidity(%),Outdoor Temperature(℃),Outdoor Humidity(%),Dew Point(℃),Feels Like(℃),Wind(m/s),Gust(m/s),Wind Direction(deg),ABS Pressure(hPa),REL Pressure(hPa),Solar Rad(w/m2),UV-Index,Console Battery (V),External Supply Battery (V),Charge,Hourly Rain(mm),Event Rain(mm),Daily Rain(mm),Weekly Rain(mm),Monthly Rain(mm),Yearly Rain(mm) 2024-09-18 14:25,22.8,55,23.2,54,13.4,23.2,1.1,1.6,259,989.6,1013.1,519.34,4,5.47,4.84,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:29,22.8,54,23.1,53,13.0,23.1,1.6,2.0,348,989.4,1012.9,519.10,4,5.51,4.82,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:34,22.8,54,23.1,55,13.6,23.1,3.5,3.9,194,989.7,1013.2,195.74,1,5.57,4.84,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:39,22.8,54,22.9,55,13.4,22.9,0.5,1.6,305,989.8,1013.3,187.92,1,5.61,4.85,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:44,22.8,54,22.9,54,13.1,22.9,1.5,2.2,329,989.6,1013.1,215.94,2,5.65,4.84,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:49,22.8,54,22.7,55,13.2,22.7,5.1,5.6,254,989.7,1013.2,526.12,4,5.69,4.83,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:54,22.8,54,22.7,56,13.5,22.7,0.7,2.0,285,989.5,1013.0,221.23,2,5.73,4.84,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 14:59,22.8,54,22.9,56,13.7,22.9,0.5,1.1,121,989.3,1012.8,463.69,4,5.76,4.84,1,0.0,0.0,0.0,0.0,0.0,0.0 2024-09-18 15:04,22.8,54,23.2,54,13.4,23.2,1.9,3.9,252,989.2,1012.7,143.80,1,5.78,4.85,1,0.0,0.0,0.0,0.0,0.0,0.0
the YYYYMMAllSensors_Z.CSV files contain all the extra sensor data beyond the basic sensors
example
202501AllSensors_B.CSV
Time,CH1 Temperature(℃),CH1 Dew point(℃),CH1 HeatIndex(℃),CH1 Humidity(%),CH2 Temperature(℃),CH2 Dew point(℃),CH2 HeatIndex(℃),CH2 Humidity(%),CH3 Temperature(℃),CH3 Dew point(℃),CH3 HeatIndex(℃),CH3 Humidity(%),CH4 Temperature(℃),CH4 Dew point(℃),CH4 HeatIndex(℃),CH4 Humidity(%),CH5 Temperature(℃),CH5 Dew point(℃),CH5 HeatIndex(℃),CH5 Humidity(%),CH6 Temperature(℃),CH6 Dew point(℃),CH6 HeatIndex(℃),CH6 Humidity(%),CH7 Temperature(℃),CH7 Dew point(℃),CH7 HeatIndex(℃),CH7 Humidity(%),CH8 Temperature(℃),CH8 Dew point(℃),CH8 HeatIndex(℃),CH8 Humidity(%),WH35 CH1hum(%),WH35 CH2hum(%),WH35 CH3hum(%),WH35 CH4hum(%),WH35 CH5hum(%),WH35 CH6hum(%),WH35 CH7hum(%),WH35 CH8hum(%),Thunder count,Thunder distance(km),AQIN Temperature(℃),AQIN Humidity(%),AQIN CO2(ppm),AQIN Pm2.5(ug/m3),AQIN Pm10(ug/m3),AQIN Pm1.0(ug/m3),AQIN Pm4.0(ug/m3),SoilMoisture CH1(%),SoilMoisture CH2(%),SoilMoisture CH3(%),SoilMoisture CH4(%),SoilMoisture CH5(%),SoilMoisture CH6(%),SoilMoisture CH7(%),SoilMoisture CH8(%),SoilMoisture CH9(%),SoilMoisture CH10(%),SoilMoisture CH11(%),SoilMoisture CH12(%),SoilMoisture CH13(%),SoilMoisture CH14(%),SoilMoisture CH15(%),SoilMoisture CH16(%),Water CH1,Water CH2,Water CH3,Water CH4,Pm2.5 CH1(ug/m3),Pm2.5 CH2(ug/m3),Pm2.5 CH3(ug/m3),Pm2.5 CH4(ug/m3),WN34 CH1(℃),WN34 CH2(℃),WN34 CH3(℃),WN34 CH4(℃),WN34 CH5(℃),WN34 CH6(℃),WN34 CH7(℃),WN34 CH8(℃),LDS_Air CH1(mm),LDS_Air CH2(mm),LDS_Air CH3(mm),LDS_Air CH4(mm), 2025-01-10 12:19,1.7,0.7,1.7,93,3.2,1.4,3.2,88,1.4,-0.2,1.4,89,--,--,--,--,-22.5,--,--,--,3.6,2.4,3.6,92,7.2,-3.1,7.2,48,--,--,--,--,--,--,--,--,--,--,--,--,0,--,15.5,59,714,12.4,13.8,--,--,61,45,56,72,50,--,--,--,--,--,--,--,--,--,--,--,--,--,--,--,--,--,--,--,2.5,--,--,--,--,--,--,--,--,--,--,-- 2025-01-10 12:24,1.7,0.7,1.7,93,3.3,1.5,3.3,88,1.4,-0.2,1.4,89,1.6,-0.2,1.6,88,-22.0,--,--,--,3.7,2.5,3.7,92,7.1,-3.2,7.1,48,--,--,--,--,70,--,--,--,--,--,--,--,0,--,15.3,60,761,6.7,6.7,--,--,61,45,56,72,50,74,--,--,--,--,--,--,--,--,--,--,--,Normal,--,--,--,9.0,--,--,2.5,2.7,1.8,--,--,--,--,--,--,--,--,-- 2025-01-10 12:29,1.7,0.7,1.7,93,3.3,1.5,3.3,88,1.4,-0.2,1.4,89,1.6,-0.2,1.6,88,-20.0,--,--,--,3.7,2.5,3.7,92,7.0,-3.3,7.0,48,--,--,--,--,74,--,--,--,--,--,--,--,0,--,15.6,59,760,8.3,8.3,--,--,60,45,56,72,50,74,--,--,--,--,--,--,--,--,--,--,--,Normal,--,--,12.0,9.0,--,--,2.5,2.6,1.9,--,--,--,--,--,--,--,--,-- 2025-01-10 12:34,1.8,0.8,1.8,93,3.3,1.5,3.3,88,1.5,-0.1,1.5,89,1.6,-0.3,1.6,87,-19.3,--,--,--,3.9,2.7,3.9,92,7.0,-3.0,7.0,49,--,--,--,--,77,--,--,--,--,--,--,--,0,--,15.3,60,775,6.4,6.7,--,--,60,45,56,72,50,74,--,--,--,--,--,--,--,--,--,--,--,Normal,--,--,12.0,9.0,--,--,2.5,2.5,2.0,--,--,--,--,--,--,--,--,--
the http API call for retrieving the SD card info is:
http://IP-address/get_sdmmc_info
information provided:
- card information (type, size, speed, archiving interval)
- file information (name, type, size; type 1 = csv)
sample result:
{ "info": { "Name": "SZYL", "Type": "SDHC/SDXC", "Speed": "20 MHz", "Size": "7580 MB", "Interval": "5" }, "file_list": [{ "name": "202409A.csv", "type": "1", "size": "3212" }, { "name": "202409Allsensors_A.csv", "type": "1", "size": "10075" }, { "name": "log", "type": "2", "size": "-" }, { "name": "202401A.csv", "type": "1", "size": "604" }, { "name": "202401Allsensors_A.csv", "type": "1", "size": "2123" }, { "name": "202409B.csv", "type": "1", "size": "398829" }, { "name": "202409Allsensors_B.csv", "type": "1", "size": "1160913" }, { "name": "202410B.csv", "type": "1", "size": "1051061" }, { "name": "202410Allsensors_B.csv", "type": "1", "size": "3039518" }, { "name": "202411B.csv", "type": "1", "size": "986611" }, { "name": "202411Allsensors_B.csv", "type": "1", "size": "2861108" }, { "name": "202412B.csv", "type": "1", "size": "78625" }, { "name": "202412Allsensors_B.csv", "type": "1", "size": "228437" }] }
to get the content, the API call is
http://IP-address:81/filename (where filename is YYYYMMZ.csv resp. YYYMMAllSensors_Z.csv)
this initiates the download of the file
——————————————————————————————————————————————————————————————
WH2600 - Ambient ObserverIP 1.0 (legacy)
The WH2600 or ObserverIP 1.0 was the first displayless console (“gateway”) manufactured by FineOffset and sold via many different resellers. The concept experienced a significant functional upgrade with the GW100 and the WH2650 WLAN version of the gateway.
The GW2000/3000 and the Ambient Observer IP2 and IP3 models now come with both LAN and WLAN interfaces
The evolution roadmap was LAN –> WLAN –> LAN + WLAN
The ObserverIP module is a small network device based on an ASIX microcontroller. The microcontroller contains the Ethernet PHY, flash, RAM and TCP/IP acceleration, and interfaces with the onboard radio receiver to obtain data from the indoor and outdoor sensors. It is compatible with the Ambient WS-1000/WS-1002 outdoor array (Ecowitt WH24 - the “boat”) used in the Ambient WS-1200, WS-1400, WS-1000-WiFi and WS-1001-WiFi packages as well as with the WH65 outdoor array. This array transmits in its Ambient version at 915 MHz (868 MHz versions also available under different brand names like Renkforce WH2600) with a 100 m maximum range via line of sight.
It comes with an Ethernet LAN interface.
It is not to be confused with the more modern WH2650 WiFi edition or even the WH2682 (Ambient ObserverIP 2.0) which at first glance look very much alike.
Still today (March 2024) some vendors try to sell this shelf-warmer “Middle-Age” piece to innocent weather station newbees.
—————————————————————————————————————————————————————————————————
WH2650/WH2680
The WH2650 is so-to-say a GW1000 in a different design. Instead of the wired T/H sensor, a wireless WH32B is supplied, which can be positioned anywhere and independently of the base. The device shares the identical firmware with the GW1000 - so it also behaves accordingly.
A display is also missing here. API capability and access to real-time data via the WS View or WS View Plus app (>= 2.0.30) for the WS90 are provided. This station can also work with all available sensors.
Interestingly, Ecowitt itself does not offer this Fine Offset device - so it is currently only available from resellers (such as Froggit or Steinberg) or directly from Fine Offset as WH2680 (enquire by email).
Basically, the WH2650-WiFi is an upgraded WH2600 (ObserverIP), which only enables a LAN connection [there are still remaining devices on offer, e.g. Renkforce 2600] and is (was) limited to receiving the basic sensors wind, rain, temperature/humidity/air pressure and solar. Now available for all currently available Ecowitt sensors and with WLAN (“WiFi”) interface instead of LAN (Ethernet).
Basically, the WH2650-WiFi is an upgraded WH2600 (ObserverIP), which only provided a LAN connection [there are still residual devices available, e.g. Renkforce 2600] and is (was) limited to receiving the basic sensors wind, rain, temperature/humidity/air pressure and solar. Now, as the WH2650, it is available for all currently available Ecowitt sensors and with WLAN (“WiFi”) interface instead of LAN (Ethernet) except for the IoT sensors.
In the USA, FineOffset/Ecowitt distributes via Ambient a successor to the ObserverIP “module” (console/gateway, 915 MHz), the ObserverIP 2.0 module or WH2682 console/gateway, which can receive all currently available Ambient sensors and has both a LAN and a WLAN interface as well as a WebUI (the same as a GW2000). Like all Ambient consoles, these are set via firmware so that they cannot process Ecowitt sensors (Ambient distribution policy), whereas Ecowitt (clone) consoles can also receive and process Ambient sensors. Basically, the WH2682 (ObserverIP 2.0) is a variant of a GW2000 reduced to ambient sensors and packed into the ObserverIP shell.
Froggit: WH2600Pro WIFI
————————————————————————————————————————————————————————————————-
WH2682 / Ambient Weather Hub 2.0 / ObserverIP 2.0
The WH2682 (so far 915 MHz only) is so-to-say the Ambient version of the GW2000, however with all the general restrictions which apply to Ambient consoles (i.e. the cannot process signals from Ecowitt sensors - exception is the WH32 outdoor which Ambient has depreciated and likely (to-be-confirmed) an Ecowitt WH32B/WN32P TH&P indoor sensor).
the WH2882 has a WLAN and a LAN interface and can be configured via its WebUI (https://IP-address-WH2682).
if it can also be configured with the WS View Plus app or the awnet app (the Ambient version of the old WS View app) also has to be found out.
With version 2.0.48 of WS View Plus the WH2682/ObserverIP 2.0 Hub can (still) be configured and the live data can be viewed. However, as per Ecowitt, this is sort of a negligence from their part as this was not a feature request from Ambient. Hence this may get disabled in future WSV+ versions.
Like the WH2650 it has no inbuilt sensors. This means that it needs a separate T&HP sensor (WH32B/WN32P/WH32 indoor) to provide indoor Temp/Hum and air pressure data. For outdoor arrays it is limited to the three available arrays (Ambient versions of the WN67, WS69/WH65 and the WS80). All Ambient extra sensors can be received and processed.
While the Ethernet/LAN interface can be given a static IP address, this is not (yet ?) possible for the WLAN interface (“WiFi”) [firmware version 2.2.6]
WebUI of the WH2682 / ObserverIP 2.0
————————————————————————————————————————————————————————————————-
Ambient Weather Network Hub 3.0 new edition
Since about May/June 2024 Ambient offers the new design Weather Hub 3.0 as the successor of the Observer IP 2.0 module/Weather Hub 2.0 - the black box in the legacy of the Observer IP 1.0 module.
Another name is Ambient Weather Network Hub IP3.
While Ecowitt in the redesign of its GW2000, the new GW3000, went back from the saucer design to a matchbox design, Ambient chose to make the saucer grow vertically and ended up with a cylindric shape. Like the Ecowitt GW3000 it also comes with a micro SD card slot - whose existence, functionality and use is completely omitted in the otherwise meticulous manual (September 2024).
When asking support@ambientweather.com, the following reply (excerpt) was provided:
“I do apologize for the inconvenience, we are working on updating our user manuals for this exciting new product! The SD slot can hold a memory card and write data directly from your weather station and additional compatible sensors.
This data can be collected at intervals between 1-240 minutes (4 hours), and is saved in a CSV format. The data writing intervals and other settings are accessible through the Weather Hub's web GUI.”
The SD card can be filled with the console data (observations and deduced calculations) in a freely selectable interval from 1 - 240 minutes in the WebUI as a CSV file. 0 = no data archiving. Also, the data can be downloaded via the WebUI.
The SD card type can be SDXC - therefore, also higher capacities are possible. Even though to fill a 32 GB SD card with sensor data (all possible sensors and their maximum number) will take about a decade.
The supported sensors are all Ambient branded sensors.
The structure and naming rules of the CSV files are the same as with the Ecowitt WS6210 and GW3000.
The WebUI looks the same as the WH2682/ObserverIP 2.0 module described above - plus a menu item for the SD card management.
For an example see below with the WS6210 WebUI. There the SD card management page is shown which is the same for the Ambient Weather Network Hub - only that the WS6210 and the GW3000 will save all available sensor data without the Ambient restrictions.
————————————————————————————————————————————————————————————————-
WS6006 3G/4G
The WS6006 is the console of a 3G/4G weather station.
The use case scenario are locations where neither external power supply nor Wifi connectivity would be available and the only means for communication would be the mobile 3G/4G network. Therefore the console comes with rechargeable batteries and one or two solar panels for power supply.
A permanent power supply via USB is also possible.
The original setup was the console plus an inddor sensor plus the WS69 outdoor array - and one or two solar panels for power supply (charging the inbuilt rechargeable batteries for operation during the night and/or during periods of low solar exposition.
Meanwhile the console also supports a WS80 6-in-1 sensor array and a WH40 rain gauge instead of a WS69.
In both cases an additional WH32 outdoor T/RH sensor, one WH51 soil moisture sensor, one WN34 temperature sensor, one WN35 leaf wetness sensor and a WH41 PM2.5 air quality sensor can be added.
Pre-requisite: firmware >= 1.1.32 (see also max sensors per console matrix)
special features, restrictions and tips
- Sends alarm messages via SMS
- data is saved as CSV file on the SD card
- transmission span time via WCDMA network is programmable by user from 10 minutes to 24 hours (or switched off)
Pushes sensor data to cloud weather services:
- one custom site using Wunderground protocol only (Ecowitt protocol not supported !)
for the transmission into the mobile network to work, the SIM card must not have a PIN set
The general setup is depicted in the following picture
WS6210 3G/4G
The WS6210 is the successor model of the WS6006 3G/4G console.
the gateway has been released in September 2024 and comes with a very comprehensive manual.
features
- 3G/4G but no 5G support
- Ecowitt protocol for custom server supported (WS6006 has WU protocol only)
- reduced posting interval restrictions: 0, 1, 2, 3, 4, 5, 10 minutes selectable
- all outdoor sensors and arrays supported
(WS6006 has WS69 and WS80+WH40 only, + one WH34, WN35, WH41, WH51 each)
(there is no restriction in numbers per sensor other than with e.g. a GW2000 gateway) - all IoT sensors supported
- SD card > 32 GB supported (SDXC)
The console has the usual gateway (“AP” - access point) with the SSID WS6210x-WIFIxxxx and the IP address 192.168.4.1 inside its local WLAN - and it can also be connected to a local network router, where the location/use case allows.
The gateway will have three working modes:
1. 4G only
2. WLAN/WiFi only
3. WLAN/WiFi with 4G fall-back option
Gateway-sensor combinations (station models, station kits) will be sold under the model brand name WittField
Its WebUI looks like this:
for the structure and the naming rules of he CVS files follow this link
even with no local WiFi network available, data can be retrieved via the inbuilt WLAN/Access point when close to the console with a WiFi-enabled device (laptop, smartphone, …)
typical use cases would be remote station locations which are out of reach of WLAN access points (countryside, agriculatural areas, small airports [e.g. near runways], boats …)
as a station design proposal (agricultural use case) a model consisting of T/RH outdoor, rain, and solar/wind sensor (mounted on a provided tripod if ordered) are offered - example:
WS6212 or WittField Suite: WS6212 (WS6210 + WH40 + WN32 outdoor + WS68) | WS6211 or WittField Combo (WS6210 + WS69) | ————————– WS6210 stand-alone |
---|
there are also configuration options with a WS80 or WS90 array including building your own station from the components as usual.
a peep into the SensorsID page of the WebUI doesn't indicate any sensor type or number restrictions compared to a GW1200 or GW2000.
WS6210 inside
the WS6210 comes with a 3-month-free (300 MB total data volume) SIM card of a provider in the ordering country (or as agreed with Ecowitt sales at the order process) and an 8 GB micro SD card. The SIM card can be extended or a personal SIM card with a provider of the customer's choice can be used.
The SD card can be exchanged with a piece of different storage capacity SDHC/SDXC type, FAT32 formatted.
For SD card > 32 GB Ecowitt recommends to use the public domain tool Rufus for FAT32 formatting (max size of a FAT32 partition is 2 TB): Rufus Tool
How many Megabytes does one post per minute generate per month ?
the post string of a GW2000 with rain and piezo, 7 WH31, 6 WH51, 2 WN34, 2 WH41, 1 WH55, 1 WN35, 1 WH45 and 1 WH57 has a size of about 2 kBytes (exactly 1,954 bytes) =⇒ 2 x 60 x 24 x 31 = 89,280 kbytes (~ 87 MB) - you can add about 30 bytes per additional sensor per post.
With the maximum number of sensors connected and a post every minute, a data usage of about 130 MBytes would be generated.
There are also eight (8) 2400 mAh rechargeable batteries included and a USB charging cable (70 cm / 2.3 ft long).
The connection cable for the solar panel is 50 cm/ 1.6 ft long.
No power supply is provided - a power supply (5 V / min 1 A) has to be provided by the customer.
We recommend using a stable (usually not the cheapest models) power supply as unstable power supplies are a known cause for console/gateway malfunctioning.
the latest firmware 1.0.5 puts the gateway into sleeping mode once the voltage goes below 4.5 V to protect the batteries from over-discharge and potential short circuit.
In a test on batteries only and WiFi on with a one minute posting interval to ecowitt.net and a local custom server post (but AP off), four 1200 mAh batteries hold for about hours. With sufficient solar exposure the solar panel can delay reaching the stand-by mode threshold. With the full install ( 8 x 2400 mAh batteries) the time before going into stand-by can be extended by 24 hours in such a setup. Running on 4G only with a 5 or 10-minute posting it would probably run for a month or longer depending on season and solar exposure during the day.
typical scenarios - outdoor and indoor with 4G fall-back option
another hybrid (WLAN/4G) scenario would be the WS6210 gateway located outdoors but within the range of a 2.4 GHz WLAN access point.
for the time being - out of security concerns - connected IoT devices can only be configured and managed with the Ecowitt app (WSV+ to follow) but not via the WebUI
WS6210 test mount | —————————————————-initial charging |
---|
————————————————————————————————————————————————————————————————-
Display Consoles
recently (December 2024) available Ecowitt display consoles |
---|
for reseller (clone model) names see brand model translation table
————————————————————————————————————————————————————————————————-
HP1000 (legacy)
also known as Ambient WS-1000/1001/1002, Froggit 1000SE, Fine Offset HP1000/1001/1002/1003
The HP1000 series is the pre-decessor series of the HP25x0 series and is already WLAN enabled.
There are different versions of the HP1000 console.
One with 39 MB memory and one with 4 GB (3826 MB).
The latter runs on WindowsCE.
Some of the WH24 outdoor arrays (“boat”) have an inbuilt lightning detector (WH60) which can be switched on or off for console display. A lot of the configuration takes still place (or can also take place) via configuration files which are transferred with a firmware upgrade.
Some stations were sold with the more modern WH65 outdoor array.
As the identifier and transmission protocol for the WH24 and the WH65/WS69 are the same, they can be interchangeably used.
the last available firmware for the 4 GB model can be found here
the console management software here.
————————————————————————————————————————————————————————————————-
WH2315 (legacy model with USB port)
this is the predecessor model of the WS2320
the data retrieval and display software can be found here: weathersmart_setup1.9.4_0530_.zip
————————————————————————————————————————————————————————————————-
WS2320
Probably the oldest WiFi-enabled console/weather station in the programme. Only the outdoor sensor group or unit (array) WH65 (Y-shape) / WS69 (I-shape) is supported as sensors.
However, the data can also be accessed remotely via WLAN using the Windows software WeatherSmart for WiFi or WeatherSmartIP. This saves the data locally in an MS Access database at the selected interval (16s, 30s, 1 min, 5 min, ….) and displays it in a window (PC interface).
The console itself can store approx. 3500 data records (one data record per selected interval) internally; if the memory is full, the oldest data record is overwritten, i.e. the software does not have to run 24/7 in order to store the data on the PC without gaps. The missing data is read from the console and transferred to the database when the programme is restarted. It should be noted that these 3500 data records with a storage interval of 30 seconds are only sufficient for just over a day. Even with a 3-minute interval, the 3500 data records are only sufficient for just over a week. And even with a storage interval of 300 seconds (5 minutes), the station can only record data for just over 12 days without the first measured values being overwritten. The console and PC interface are updated every 16 seconds. The data can be displayed as graphs or tables and exported as CSV files or JPEG files.
The console has a 5V power supply and a battery backup. It is the largest console in terms of screen size. The screen format is 4:3. This station no longer requires a USB interface (WiFi!) and therefore no longer has one.
A question sometimes asked - what does this little rain cloud icon mean and why is it sometimes blinking?
In the bottom left corner of the rain tile of the display a lttle cloud with rain drops appears when a rain event (definition –> WH40) is still going on. (Left of the period indicator: day, week, month … if you are in rain period view). In case of expected storm conditions, this cloud icon starts blinking.
a storm condition : a sudden barometer pressure drop for over 3 hPa over the past two hours detected
Froggit: WH4000SE
————————————————————————————————————————————————————————————————-
WS2910/WH2910 (Ambient WS-2902A thru D)
This is probably the by far most sold Fine Offset manufactured console (and station) model, which can be found under a host of model names.
Unfortunately, this console/station does not support all current (2023) sensors and - unlike the HP2551C - does NOT have a slot for an SD card.
From device firmware V2.1.9 on (Attention! device firmware is not updateable!) up to 8 WH31 and 2 WH41/WH43 are accepted and also forwarded to external services, but these are not displayed on the console screen.
To clarify this again: For the WH2910 to be able to transmit the values of the additional 8 WH31 and 2 WH41/WH43, the device firmware must be >= v2.1.9. However, it is not possible to upgrade from an earlier (lower) firmware version to 2.1.9!
The current version of the device firmware is displayed at the top left when the console is started. In the example image, this is the device firmware v2.1.13, which supports the extended sensors.
Firmware version display of WH2910
In addition to the device firmware that cannot be updated (see above), there is also a WIFI firmware that can be updated via WS View. This app can also display the current WIFI version (EasyWeather vX.YY).
The Ambient WS-2902D console has already a new WiFi modem and firmware (AMBWeatherPro analogous to the Ecowitt EasyWeatherPro) with an inbuilt webserver page which can be reached either via 192.168.4.1 when connected to the local WLAN of the console (SSID: AMBWeatherPro-xxxxxx) or, once the pairing is established, via a web browser to the IP address of the console (http://IP-address-of-console). Posting to weather networks is via this WebUI. Posting to WU (wunderground) can only be made using the customized server functionality.
History of Ambient WS-2902 consoles and last letter meaning
WS-2902: | Initial product release. Used Ambient Tool app for WiFi setup |
---|---|
WS-2902A: | Added Wi-Fi broadcast mode. This enables users to connect their console to their dual band router without having to disable the 5.0 GHz band |
WS-2902B: | Supports 8-channel thermo-hygrometer sensors and PM2.5 sensors. They cannot be viewed on the display console but are passed through to the Ambient Weather Network |
WS-2902C: | Improved console layout. |
WS-2902D: | Console layout improved. Web GUI Wi-Fi setup interface added. Wi-Fi connectivity enabled; Awnet app no longer needed; new firmware AMBWeatherPRO-xxxxxx |
Froggit: WH3000SE
————————————————————————————————————————————————————————————————-
HP2550/HP2560 - Ambient WS-2000/WS-4000/WS-5000 - Froggit HP1000Pro SE/HP2000
Note:
the Ambient WS-2000, WS-4000, WS-5000 consoles are technically the same console. The only difference is the Ambient product name. They can all receive the same Ambient sensor arrays (WS-2000/4000/5000-ARRAY) and sensors. The difference comes from the Ambient sales policy only to sell console/sensor bundles and to force users with a wish to upgrade into buying also a new console.
there are still differences - see differences Ambient WS-2000/4000/5000 and Ecowitt HP25x0 consoles
The HP2551 station is sold by Ecowitt with the HP2551C console and the standard WH65/WS69 sensor array. The same console is offered with individual sensors WH40 (rain gauge) and the ultrasonic anemometer WS80 as a bundle as HP2553 station. Neither indoor temperature, humidity nor air pressure sensors are installed. Instead, the device is supplied with a 3-in-1 WH32B or WH32 indoor sensor (temperature, humidity, air pressure - also called T&HP), which can be positioned anywhere in the room without cables. The HP2551C console measures 19.5cm x 13.7cm and has a display area (TFT) of 15.5cm x 8.7cm. It can be read out via the PC weather station software Wswin using the wswin_x-csv_hp2550.
There are two different firmware updates for this console (as well as for the other consoles with a display screen), which must be installed in different ways. The device firmware user.bin or factory.bin must be imported via microSD card (SDHC, max. 32GB, FAT32). To do this, copy this file to the root directory of the microSD card using an SD card reader and insert the card back into the station. This automatically recognises a newer version and imports it from the SD card, deletes the file on the SD card (Attention! The factory.bin is NOT automatically deleted and must be deleted by the user if necessary) and restarts the device.
With v1.7.3 of this firmware from June 2021 there is - in addition to an adaptation of the translation into German - the possibility of naming all sensors yourself. Since the way to do this is not described in the original manual, here is a quick guide:
from the main view, press the button with the up/down arrow 4 times since firmware 1.7.8, the way to get there has been changed ; now it is Gear → More [Settings] → Sensor names & data - this takes you to the sensor overview then navigate to the individual sensors using the cursor keys The name can then be edited using the magnifying glass “-” [(-)].
The current device firmware can be found at Ecowitt under Manual & Software on the HP2551 and HP2553 pages. Froggit usually offers the firmware version for the HP1000SE Pro with a slight time delay. However, as both firmware versions are identical (Froggit uses the original firmware from Ecowitt), you can also install the firmware for the HP2551C and thus gain some time. The same applies for the Ambient versions of the HP2550 console, the Ambient WS-2000/WS-4000/WS-5000.
There is also a WIFI firmware that is automatically found and installed by the WS View app (Android, iOS). It is therefore worth starting this app from time to time to check whether an update is available.
Firmware updates enable new sensors to be processed and any errors to be rectified or functions to be extended. Firmware updates are therefore highly recommended (even if you don't necessarily have to be the first). However, Ecowitt is now considering the use of an (external) beta group to test new firmware versions.
A detailed description of the (possible) displays on the console main page can be found can be found below. firmware upgrade
In the meantime (April 2022) Ecowitt has released the successor model, HP2560. Apart from changes in the design (legs instead of fold-out support and fold-out internal sensor for temperature and humidity; air pressure sensor on the circuit board), which are certainly a matter of taste, there do not seem to be any other functional changes apart from the no longer existing possibility of separating the console location and the internal temperature/humidity/air pressure sensor, which some will certainly miss. Some speak ironically of an HP2550 on stilts and with a flagpole. Whilst the screen is the same size, the frame has been reduced in size. See comparison photo. See also note below at WH32B/WH32 indoor. The “stilts” are a holder from which the actual console body can be removed or into which it can be pushed. Like the HP2550, the HP2560 also has a “stilt” on the back.
With the latest firmware version, a separate, remote T&HP indoor sensor (temperature/humidity/air pressure), the WH32 indoor/WN32P sensor which also the HP2550 console uses, can also be used again with the HP2560 console (Froggit HP2000), but only with a hardware intervention. To do this, the four wires leading from the T/RH sensor (“antenna”) to the main board must be “clipped”, i.e. either cut off (pliers) or desoldered. When using pliers, it is advisable to cut the wires as close as possible to the main circuit board. If the firmware does not find an indoor T/RH sensor, it will allow a WH32B (indoor) sensor to be registered as an alternative. This has been confirmed by Ecowitt and also successfully carried out by a wxforum.net user. Such an intervention naturally leads to the loss of warranty claims in the first year, at least with Froggit. Ecowitt is not so rigid here, unless there was recognisable damage to the inner workings of the console during the intervention. With the necessary care, however, this should not happen.
Menwhile (August 2024) the separate T&HP sensor option is also available for the HP2560 console. With device firmware 1.9.5 the hardware intervention is no longer necessary and a separate T&HP sensor can be registered to a HP2560 console.
The HP2560 and also newer HP2551 models have a new, different WLAN/WiFi modem than the HP2551. Therefore, it also requires its own WiFi firmware (EasyWeatherPro - see firmware below).
Together with the new firmware, the configuration of the weather services can also be accessed via a browser. A firmware update of the WIFI firmware can now also be carried out via the WebUI.
However, there is no display of the current measured values (live data) or access via http API as with other consoles (GW1100, GW2000, WN1980C).
The newer HP2551 clone consoles supplied by Froggit (HP1000SE Pro) already have the new WiFi modem hardware and the new WiFi firmware as well as a WebUI.
In the long term, there should be a standardised WiFi firmware again, which will then be called EasyWeatherPro for all consoles that have separate WiFi firmware.
We will certainly know more soon and will be able to update this section.
Data access/retrieval
The HP2551C unfortunately lacks a mechanism to access the stored data remotely.
Other stations offer a USB interface for this (such as the HP3501) or allow access via the network (such as the WH2320).
The HP2551C does not support this!
The HP2551C also has a USB interface. However, this is probably only intended for internal use with Fine Offset.
And of course this console is accessible via network. However, it does not support data retrieval, but only the setting of data transmission to weather networks and a self-selected (customized) server.
By inserting a microSD card (SDHC, max. 32GB, Fat32) and configuring the station accordingly, the HP2551C can save all data as a CSV on the SD card at a configurable interval. According to current calculations with the CSV files available from a HP2551C and several sensors at a storage interval of 60 seconds, one gets approx. 20 MByte of CSV data per month. That's 240 MBytes per year; so 8 GB should be enough for at least 30 years.
Here too, however, there is no way to access this data remotely. So you have to remove the SD card from the station and only THEN can you access the data stored on the SD card, for example using an SD card reader.
However, you can define a destination to which the station console automatically sends the current data at configurable intervals. (see Custom Server below)
This destination can also be local - but requires a remote server that receives and processes this data 24/7.
Technically, the station sends the current data record in ASCII via http/POST.
The destination can be a webhost server with a specially created PHP script.
However, there are also more comprehensive software solutions that have a much wider range of functions in addition to CSV generation, such as weewx, CumulusMX, Meteobridge or FOSHKplugin.
You cannot query the data. But you can retrieve the data via SD card or have it posted to a choosen target address (customized server) at intervals.
In case of a defective console display, see also HP2550 console display repair
Remember: Ambient consoles can only receive Ambient branded sensors - Ecowitt (and clone) consoles can receive sensors of all brands.
permanent automatic sea level pressure adjustment
from device firmware 2.0.0 on the normalized sea level pressure (REL) will be calculated by the console and updated whenever either the outdoor temperature, humidity or the local station pressure (ABS) change.
you will have to enter your barometer altitude for this
(Altitude = ground elevation plus height of the barometric sensor above ground)
the automatic SLP update feature with device firmware 2.0.0 has also been tested on Ambient WS-2000/4000/5000 consoles and works there also - the REL pressure field is repurposed to an altitude field
———————————————————————————————————————————————————————————————————-
the main display/interface of the HP2550/2551 console and the 2nd generation HP2560 console
the main display/interface of the HP2550/2551 console and the 2nd generation HP2560 console
(also Ambient WS-2000, WS-4000, WS-5000 consoles - for sensors see translation table)
13. A red (!) symbol indicates that a set alarm was triggered for the respective sensor
14. For each sensor there is a red battery symbol, which is invisible in normal operation and appears to the left of the reception display of the relevant sensor when the battery is lowap pears to the left of the reception display of the relevant sensor.
since device firmware 1.9.5 when the rainfall priority is set to piezo, the text “Piezo” appears under the “Daily Rain” text.
In addition to (1): the WU and Ecowitt icons are shown in the picture as examples - two more weather service icons are possible: WeatherCloud and WOW - (shown will be the one(s) that have been set up in the console and where successful data posting is going on)
In addition to (5): for the definition of a rain event, see the WH40 Rain gauge
(3) with console firmware 1.7.6 the time stamp of the last strike is now maintained over a reboot or restart
(before it would disappear after a reboot/restart of the console)
(5) the console does not show 24h rain [yet] (=rainfall during the previous 24 h - not to be confused with 24 h/daily total rainfall)
Next (left) to the reception quality symbol of each sensor is a low-battery warning symbol, which is invisible during normal operation. It will appear only when the battery power has dropped too much.
the colour coding of the temperature display
(outdoor big circle left - indoor and extra temperatures smaller circle right)
There are three different colours for the alarm symbol:
- red if a maximum value has been activated,
- blue if a minimum value has been activated and
- yellow if maximum and minimum values have been activated.
If the maximum value is exceeded or the minimum value is undershot, the symbol flashes and a beep sounds, which stops when any button is pressed. The alarm symbol continues to flash until the threshold values are reached again.
However, the alarm is also displayed for sensors in the right-hand temperature circle if a temperature sensor other than the indoor temperature sensor is displayed (in the cycling mode display).
No alarm can be set for the WH31 and WH45.
the general time alarm symbol (!) is shown between the year of the actual date and the time
10-minute average wind speed display
the HP25x0 console is the only Ecowitt console to display the 10-minute average wind speed. (see picture above, display description, section 8).
with device firmware 1.9.9 the algorithm has been changed to comply with WMO recommendations:
sum over the wind speed values per transmission / number of transmissions in the past 10 minutes
vaverage = (x1 + x2 + x3 + x4 + …. + xn)/n
(the transmission interval for a WS68/69 is 16 seconds, for a WS85/90 8.8 seconds and for a WS80 4.75 seconds)
saving/archiving historic data (memory, SD card)
the HP25x0 consoles saves every x minutes the basic weather data (wind, rain, outdoor and indoor temperature/humidity, solar, UV, pressure) to its memory. Extra sensor data are not stored in the memory. Once the 16 MB memory is full, the oldest record will be overwritten. The archiving interval is by default every five minutes and cn be changed on the Setup page (interval) to values between 1 and 240 minutes (4 hours).
When a SD card is inserted, the basic data plus all sensor data will be written to the SD card in the archiving interval.
When a factory reset is performed, all data in the console memory will be deleted. The data on the SD card will remain untouched.
For more details see SD card management
Console power consumption
According to our own measurements, the HP2551C (old revision - without WebUI) requires approx. 500mA in operation with display and approx. 200mA when the display is switched off.
Improving the reception quality
There are sometimes complaints that certain sensors are not or only sporadically displayed in the HP25x0 console, depending on the distance and obstacles. Changing the location of the console and bringing it into the line-of-sight with the sensors often helps. However, especially with the WH51/WH31SM sensors this may not suffice.
The lack of reception often has to do not only with the console location alone but also with the built-in antenna. This is laid horizontally (a “simple” red wire 1/2 the length of the wavelength (433, 868, 915 MHz depending on the region model)). Vertical alignment usually brings a significant improvement. This does not require soldering, but simply laying the antenna in existing brackets on the inside edge of the housing. An example can be found at http://www.wetterstationsforum.info/viewtopic.php?t=1539 (in German language, use https://www.deepl.com for accurate translation).
However, this only works with an HP2550 or WS2910 console.
The HP2560 has a different interior and the antenna is installed in an elongated plastic block.
If this is not sufficient, the wire can also be routed to the outside at the top left (display view) (drill hole) and terminated with a tiltable LTE antenna. In this case, however, minimal soldering is required. Example (English): https://www.wxforum.net/index.php?topic=40585.0 With an HP2560, the LTE antenna would have to be connected to the ANT1 contacts on the mainboard (see image below right).
The CR2032 button cell is not for backup but to keep the real-time clock (RTC) alive. When it expires, the date/time is reset to 01-Jan-1070.
Reseller name: Froggit: HP1000SE Pro, DP2000 (=EW HP2560)
Froggit ships since January 2023 the second hardware revision of the HP2551 (Froggit HP1000Pro SE) console with device firmware 1.7.8 and WiFi firmware EasyWeatherPro 5.0.2;
GARNI has the HP2550 console as part of their Arcus 3055 (HP2553) station (with old and new WiFi modem)
———————————————————————————————————————————————————————————-
editing sensor display names
As the console firmware update to V1.7.3 in quite a few cases purged the name of the indoor temperature/humidity sensor shown on the main display and replaced it with the text “WH32”, the question arose how to fix this. Below the answer which is somewhat tricky and not clearly documented in the HP2551/2553 manual. On the main setup pages (pressing the wheel/gear button 1-4 times - the position changes on the 1st setup page !! - or “More [setup]” on the 1st setup page) you only find the possibility to change the display names of your WH31 extra sensors (1st setup page).
Ecowitt somehow considers the WH32B sensor, the indoor temperature/humidity/pressure not as a basic sensor (what common sense would expect as the sensor comes with the HP2551/2553 packages) but as an OPTIONAL sensor.
Hence you have to look somewhere else: on the “Optional Sensor Display Mode” page ( press 4 x ▼▲ from the main display). There you suddenly find your WH32B T/H/P sensor under the name it shows on the main display.
However the example in the manual does NOT show this sensor ….
On this page the display names of all sensors shown (all optional sensors including the WH32B) can be edited.
Select the sensor with the ▼▲ key and press the (-) key to enter the editing dialogue.
From firmware 1.7.8 on this page was moved into the “settings” area: Settings (gear wheel) –> More [Setup] –> Sensors Name&Data
(but you can still reach it via pressing 4 x ▼▲ from the main display )
———————————————————————————————————————————————————————————-
the SensorsID submenu / (re-) registering sensors
The sensors ID submenu is not properly described in the HP2551 manual (October 2021) and people trying to install a WH32B (e.g. for the HP251 or the WH2650) or the WH32(-EP) - the WH32 manual only shows how to get a WH32 installed for a GW1000/WH2650 but not for a HP2550 console where WS View only works for weather network configuration - are confronted with obstacles, I have decided to explain the SensorsID submenu below.
How to get to the sensor ID sub-menu page
Setup (gear wheel) –> More [setup] –> SensorsID
By the way - there are two submenu pages for the Sensor IDs. The 2nd one is found by pressing the arrow-right.on-a-page key (4th key from the left) when you are on the 1st SensorIDs page. The 2nd is for the WN34 and WN35 sensors, whereas the rest of possible sensors shows on sensorIDs page #1.
It's a table with three main columns, each of which has three resp. four sub-columns.
the below pictures represents device firmware 1.9.6
the little USB-A icon means that the AQIN sensor (WH45/46/46D) is powered via a DC adapter
GARNI in Europe have given own sensor names also inside the HP2550 console (their name: Aercus 3055) and do not show the WS68 and WS90 sensors
HP2550 | Aercus3055 |
---|
below the SensorsID page of an Ambient WS-2000/WS-4000/WS-5000 console on device firmware 1.9.6
comparative table of sensor acronyms on the HP25x0 sensorID page across resellers
Ecowitt (+ unmodified clones) | Ambient | GARNI |
---|---|---|
HP2550/HP2560 | WS-2000/WS-4000/WS-5000 | Aercus3055 |
WH65/69 | WS2000 | G4INT |
T&HP | WH32B | G090HP |
T&H | WH32E | T&H |
WS80 | WS5000 | G095HA |
WH40 | 5kRAIN | G007R |
WH57 | WH31L | G094L |
AQIN | AQIN | G083QC |
WS68 | N/A | |
WS90 | WS4000 | N/A |
WS85 | ||
PM2.5 1-4 | PM2.5 1-2 | G080Q |
T&H 1-8 | T&H 1-8 | G092H |
Soil 1-8 | WH31SM 1-8 | |
WH55 1-4 | Leak 1-4 | |
WN34 1-8 | ||
WN35 1-8 | WH51LW* |
Ambient has only two PM2.5 AQ sensors (WH41/43) where #1 is predefined as outdoor (WH41) and #2 as indoor (WH43).
The number of Water Leak (WH55), extra T&H (WH31/WH31E), and Soil Moisture (WH51/WH31SM) are the same: 4, 8, 8.
With Ambient it is either a PM2.5 indoor or a 5-in-1 AQUIN (WH45/46) combo sensor. Both can be registered separately in either the AQIN or IN PM2.5 sensor ID field, but only one will work - as they share the same channel.
So, you either register an PM2.5 sensor as indoor sensor (IN PM25) or an AQIN combo as AQIN.
the table is quite self-explanatory, except for the 1st main column where you find the “T&HP” and “T&H” entries.
T&HP is the WH32B sensor - the indoor temperature/humidity/air pressure sensor
T&H is the WH32 sensor - the single temp/hum outdoor sensor (all other outdoor T/H sensors are integrated in one of the three outdoor arrays, WH65, WS68, WS80, WS90 and are reported via them) - if you use an outdoor array and a WH32(-EP) outdoor T/H sensor in parallel, you will to register it here - and its readings will override the outdoor T/H readings of all the other arrays (–> Sensor Hierarchy).
The WH57 lightning detector and the WH45/WH46 indoor 5-in-1/7-in-1 air quality combo sensor also show in the first column.
The same with the WH65/WS69, WS68, WS80 and WS80 outdoor arrays.
In order to either register or deactivate a sensor, you will have to select its ID field with the up/down arrow keys and then press the (-) key.
A little pop-up window appears where you have five options:
1. Register (the console will automatically look for the sensor);
2. enter its ID and register it actively (this is useful if you have sensors of the same type and are not happy with the console's choice - or want to assign a particular sensor to a channel (see WH41/43, WH51, WH55, WH31/WN30));
3. select “disable” to deactivate the sensor
4. save (always needed except for 5.)
5. cancel
It is generally GOOD PRACTICE to actively DISABLE all sensors you do not use with your console (HP2550, GW1x00, WH2650) in the sensorsID section of your console or WS View Plus app in order to avoid wrong registrations. Do not leave the sensor ID entry in “learning” mode.
Battery exchange - Battery replacement
If you change/replace the batteries of your sensor(s), the sensor(s) might need to be re-registered in the console(s) it was (they were) registered to before !!
The 2nd main column houses the WH41/43 PM2.5 sensors (4 channels) and the WH31/WN30 Extra Temperature/Humidity sensors (8 channels)
The 3rd main column houses the WH51 soil moisture sensors (8channels) and the WH55 water detectors (4 channels)
firmware upgrade
HP2550 and HP2560 consoles with recent WiFi firmware EasyWeatherPro only !!
(also applies to Ambient WS-2000/WS-5000 consoles with AMBWeatherPro WiFi firmware)
The WiFi firmware for the newer HP25x0 console models with the new WiFi modem (EasyWeatherPro) could already be updated over-the-air (OTA: here via WiFi) earlier EasyWeatherPro versions. With device firmware 1.9.5 this is now also possible for the device firmware. This means that no firmware upgrade via SD card is necessary anymore for the newer models.
to upgrade HP25x0 consoles with WiFi firmware EasyWeather see firmware upgrade HP2550
———————————————————————————————————————————————————————————-
differences in firmware functionality between Ambient WS-2000/4000/5000 and Ecowitt HP2550/HP2560 consoles
beyond their Proprietary foreclosure policy regarding their sensors, Ambient seems to go for the cheapest solution rather than for fully fledged functionality - see also firmware differences below
- Ambient consoles only process and display Ambient branded sensors (exception WN32 as Ambient WH32E was decommissioned)
- the WS-2000/4000/5000 consoles are HP2550 clones - functionalities of the HP2560 are not taken nor the HP2560 hardware used/offered
- the temperature compensation functionality is not used (“not needed”)
- the choice between Feels like and Apparent temperature is not offered (on the MORE page) (“not needed”)
- the WS85 and WS58 do not appears on the Ambient SensorsID page (no related Ambient product exists)
- no WN34 calibration (obvious, because Ambient doesn't offer homologue WN34 sensors in their variations (S/L/D)
other facts also indicate this procurement saving and selling price maximization policy. e.g. their WS-4000-ARRAY (a diet version of the WS90 without heater and external power supply)
Also their policy trying to force users to post data to Weather Underground (WU) via AWN rather than having a preset option. This preset option for WU including WeatherCloud and WOW formerly existed and was removed from the Weather Service options of an Ambient WS-2000/4000/5000 console. If one still wants to avoid the capricious behaviour of AWN regarding WU postings, one can still post to AWN via the Customized Server.
——————————————————————————————————————-top: ——Ecowitt HP25x0 console ——————————————————————————————————————-bottom: Ambient WS-2000/4000/5000 console |
---|
It can only be speculated that there is a profit maximization approach behind the less functional hardware choices and the reduced firmware functionality. Possibly the reduced firmware functionality was a criterion for a lower procurement price. Why would one otherwise reject an added value coming for free and making the product more attractive …
The very fact that Ambient seems to lag behind device firmware upgrades probably results from the situation that the newer firmware versions, even though compatible with the WS-2000/4000/5000 consoles, do only provide functional upgrades to Ecowitt consoles and are “not needed” by Ambient.
Closely looking there isn't any advantage visible why someone (an end user) should buy an Ambient Weather Station manufactured by FineOffset rather than an Ecowitt Weather Station. Unless one has fallen into the trap of the Ambient/Fine Offset contractual agreement granting Ambient the exclusive right to sell their WS-5000 station in the USA and disallowing Ecowitt to sell their HP2553 station or even a single WS80 into the USA.
There are of course always workarounds via neighbouring countries or via K-Town in Germany if one has the proper connections which allow for a WS80 to reach the USA without the breach of the above mentioned contract. The HP2553 or GWx003 stations are still the best (ultrasonic + traditional rain) stations Ecowitt has to offer.
If someone likes the Ambient Weather Network dashboard more than the Ecowitt dashboard, they can buy a license from Ambient and have their console MAC address connected to it. And then post to AWN using the Customized Server. Still significantly cheaper than what an Ambient station costs more than the Ecowitt version with more functionality.
———————————————————————————————————————————————————————————-
using an old WH24 array ("boat") with a HP25x0/350x console
the old WH24 (Ambient WS-1001) uses a different wind measurement method and has a different funnel surface for rain readings.
While the consoles with the Ecowitt Gateway API (GW1x00, GW2000, WN19x0) have a compensation switch for a WH24 in their device settings, the HP25x0 and HP350x consoles don't.
Here one has to use different gain factors for WH24:
wind gain: 2.17, rain gain 1.18
If you want to use the new WH65/WS69 with an old WH1080 (Ambient WS-1000) console,
the gain factors are: wind gain 0.46, rain gain 0.85
————————————————————————————————————————————————————————————————-
HP3501 / HP3500
This console a much smaller display (4.3“ - just 9.5 cm by 5.5 cm) than the other consoles. However, the advantage of this station is the USB interface, which can be used to access the stored measured values with suitable software (such as EasyWeather2). Access via USB may also be possible using software under Linux such as weewx, pywws or wfrog.
On the main screen you can see the current time and date, values of the WH57 lightning sensor, the WIFI strength, a graph of the time course of a selectable sensor, wind rose with direction, wind force and gusts, 4 water leak detectors, a soil moisture sensor (presumably channel 1) and - alternating/cycling - all values of the WH45.
It also displays air pressure, UVI, solar radiation, rain rate, indoor temperature/humidity and - alternatively - outdoor temperature/humidity, dew point, Feels Like temperature and the values of the 8 possible WH31/WN30.
Except for the HP25x0 consoles, the HP350x console is the only other console to display the WH57 lightning sensor information in the top right of its display above the wind segment.
With firmware > 1.7.2 a SD card symbol with status colour appears in the top right corner of the graphical history of a chosen sensor pair when a SD card is inserted (green = normal, red = error).
An external WH32B T/H/P sensor is supplied.
The station is powered by a small plug-in power supply with a very small hollow plug (2.5×0.7mm) and 5V. If you prefer to use your own power supply, you can ensure this via a USB cable that ends in the corresponding barrel connector (e.g. AK-DC-02). There is also a USB micro socket and a microSD slot (SDHC, max. 32GB, FAT32).
The station can be calibrated like a “large” one. The rain values can also be edited.
In custom server mode, the station behaves like the HP2551C - however, the 10-minute average wind speed is not calculated. The values of the WH41, WH57, WH45 etc. are all available.
The only display language that can be set is English.
The console also offers the option of exporting the data via CSV using an optional microSD card, although not all sensor data is currently included in the CSVs - for example, the values for the WH57, WH45, WH55, WN34 and WN35 are missing. The CSV data format also differs from that of the HP2551C.
This console also contains two different firmware versions. To check the current firmware, proceed as follows:
Press the right button 7 times until the “Factory” overview appears then press the left button 4 times to go down to “About” Press the second button from the left (”+“) to go to the display.
There you will find the WIFI version in the 5th line and the version number of the device firmware in the 7th line. After approx. 45 seconds, the display automatically switches back to the main screen.
The WIFI firmware is updated as usual via the WSView Plus app. The device firmware is also transferred to this station via a microSD card.
————————————————————————————————————————————————————————————————-
WN1900/WN1910/WN1920 - Ambient WS1965
The WN1900 is a low-cost station for beginners. It consists of the bundle of WN1900C - the actual console and a special sensor array, the WN67, which is powered exclusively by batteries instead of the usual solar panel and supercapacitor. A battery storage unit with a 10 metre cable is available as an accessory, which can be used to store and replace the batteries indoors if necessary (depending on the distance between the outdoor supply group and the home). It could also be used with a WS69 (I-shape), but not with a WH65 (Y-shape). At shop.ecowitt.com the array power supply extension can be found under “Accessories for WS69”.
The outdoor sensor array of this “light-weight” WH65, the WN67 (which looks like a WS69 at first glance), also has no solar sensors.
The WN1900C console has a few interesting features, such as battery buffering and support for the GW1000 API - so there is also the option of viewing live data here.
Apart from that, it supports all known sensors that the GW1000 also supports.
In principle, it is apparently something like a GW1000 with a display - but not all sensors are shown on the display (which is understandable due to the screen size).
Nevertheless, the WN1900C could be interesting as an additional console.
The console is available (also individually, without outdoor sensor) in two versions, grey-black display [WN1900-C] or coloured-black display [WN1910-C / WN1920-C].
The WN19x0 consoles can also receive the data from a WH65 outdoor sensor group, but cannot display the solar data.
However, it can receive all solar data.
The WN19x0 consoles have the local Ecowitt Gateway API, which means that
a) they can be configured with WS View Plus app and
b) live data can be displayed in the WS View Plus app.
However, it can pass all received data (even those that it cannot display) to ecowitt.net and display them there. Basically, the WN19x0 console is functionally a GW1x00 with limited display options. The fold-out “stick” is by no means the WiFi or sensor antenna, but only houses the indoor temperature and humidity sensors.
However, there are still a few “ambiguities”: Apparently, the WN1900C uses a different chip (Opulinks) from the GW1000, GW1100, GW1200 and WH2650. At least that is what the MAC address should indicate.
Despite rumours to the contrary circulating in certain forums, a WH32 can indeed be received. However, a WH32B cannot, which is not necessary as the console has built-in T/H and air pressure sensors.
Pairing with the router requires an activated 802.11 b protocol for the WLAN component of the router. With some routers this must be activated manually! An up-to-date WS View Plus app is also required so that you can select the correct console (image) to be connected to the WLAN router. For the WN1900/WN1910, this is the image with a green screen and a blue Bluetooth symbol at the top left.
The WN1900C console has a very clear, easy to read and very tidy display with a width of 8 cm and a height of 9.5 cm. The external dimensions of the console are 10.5cm wide and 11cm high. The backlight has 4 dimming levels.
Froggit offers the WN1910 (together with light-weight outdoor sensor, WN67, without solar panel and solar data) as WH3900 - the WN1900 is not offered and the WN1980 so far not yet.
Meanwhile (March 2024) the WN1910 console has been upgraded with a WebUI and the WiFI protocols 802.11 b/g/n under the name WN1920. No more Bluetooth needed for the initial pairing. The WiFi transmission distance (2.4 GHz) is 50 m /0.55 yards.
Ambient sells the WN1920 as WS-1965 with the usual Ambient console restrictions and an Ambient version of the WN67 5-in-1 outdoor sensor array (no solar panel, no light sensor): WS-1965-ARRAY. Also, the Ambient PM25IN (~ Ecowitt WH43) cannot be registered together with an Ambient AQIN sensor (~ Ecowitt WH45) - strangely it's either or and Ambient claims that their PM25IN uses the same channel as their AQIN (CO2, PM2.5, PM10, T/RH) sensor.
During a firmware upgrade the top right tile segment which usually shows the date shows “OTA.xx” where “xx”” stands for percentage of completion. OTA stands for over-the-air and means WLAN/“WiFi” in our context.
The WN1910 console now has also got a more powerful companion, the WN1980. The display is also in colour, but shows different colours for the respective sensor values than the WN1910. In addition, it no longer uses Bluetooth for configuration but “normal” WiFI (802.11 b/g/n protocols). It also has a WebUI and the option of querying via http-API. It also no longer has buttons on the side but touch-sensitive surfaces on the display. Otherwise, the functionality is identical to the WN1900/WN1910 console.
————————————————————————————————————————————————————————————————-
WN1980
The WN1980 is apparently a slightly improved WN1910. Power is supplied via a USB3-C socket. The buttons for operation have been omitted - instead, the operating elements have been designed as touch sensors in the lower area of the display.
Finally, modern WLAN standards are also supported - this was not the case with the WN1900C resp. WN1910C where the 802.11b mode had to be activated explicitly on the router/AP, the WN1980C can also handle 802.11g/n thanks to ESP32-C3. It doesn't need Bluetooth for the initial pairing with the router either.
With firmware 1.2.3, it also supports the intelligent water valve WFC01 and the intelligent (IoT) switch AC1100 (see there).
Like the WN1900/WN1910 the WN1980 has the local Ecowitt API by which live data can be display via the WS View Plus app. In addition has the WN1980 a WebUI where configuration can be made and live data can be viewed.
The raindrops on the weather forecast display flash when storm is expected to happen. This flashing does NOT indicate that it is raining. However, in the event of prolonged rain and corresponding air pressure conditions*, the two may overlap and the drops may flash when it is raining. However, this is only due to the particular situation.
*) a storm condition : a sudden barometer pressure drop for over 3 hPa over the past two hours detected
During a firmware upgrade the top right tile segment which usually shows the date shows “OTA.xx” where “xx”“ stands for percentage of completion. OTA stands for over-the-air and means WLAN/“WiFi” in our context.
————————————————————————————————————————————————————————————————-
WN1820/WN1821 - Ambient WS-1938
Ecowitt has recently released a new console, the WN1821. Strictly speaking, it belongs to the WN19x0 series, but with a different sensor selection for the display and is more focussed on indoor climate. The WN1821 also has an inbuilt CO2 sensor. The WN1820 does not have this, but is otherwise identical.
In the CO2 display field at the top right of a WN1820, only the date is displayed; with a WN1821, you can change the date with the display of CO2 readings.
Ambient sells the WN1821 with a WH31E (WH31 multi-channel) as a stand-alone weather station (WS-1938).
It displays indoor temperature/humidity as well as all sensors belonging to the WH31 family, the WN34, WN35 and WH51 sensors (automatic alternating display or manual switching). See the image on the right for what is displayed where.
It does not display: Outdoor temperature and humidity*, solar/UV, wind, rain and air pressure.
(since firmware version 1.2.3 for WN1980/WN182x, outdoor temperature and humidity can be shown on the display)
Since firmware v1.2.7 (February 2024), a WH32B is also supported instead of the internal T/H/P sensor (Attention! the WH32B is activated by default and thus overrides the internal sensors if a WH32B is present).
During a firmware upgrade the top right tile segment which usually shows the date shows “OTA.xx” where “xx”” stands for percentage of completion. OTA stands for over-the-air and means WLAN/“WiFi” in our context.
Reseller models: Ambient WS-1938 (=EW WN1821)
————————————————————————————————————————————————————————————————-
WS3800/WS3820 and WS3900/WS3910
The WS3800/3820/3900/3910 consoles with a relatively large LCD screen (diagonal 7.5 inches/19 cm) are available with a blue and white (WS3800), a three-colour tile display (WS3820) and a colour display: colours on black background (WS3900/WS3910). They also support the WFC01 and AC1100 IoT sensors.
The consoles both have the local Ecowitt Gateway API, i.e. the data can also be displayed in real time in the WS View Plus app or in the WebUI.
The consoles have built-in T&HP sensors, but can also use a separate WH32B/WN32P T&HP sensor as an alternative.
The display update time is specified as one minute. However, in practice, the tiles update when new data is received.
The consoles both have a battery backup with three AA batteries, which protects them against short-term power failure (provided the batteries are inserted ). Continuous operation with batteries only was tested for one hour.
With firmware upgrade 1.2.9 the WiFi is switched off when running on batteries to save energy.
Also from firmware 1.2.9 on the backlight of the display can be programmed to switch off and on at a certain time. WebUI –> Device Settings.
Another interesting observation:
the display was originally updated every eight seconds only (therefore every second transmission of a WS80 would get lost) - meanwhile it can be updated every second provided a sensor update arrives.
WS3800 (down) / WS3820 (up)
The only visible hardware difference between a WS3800 and WS3820 are the 3-colour background tiles on the display and the text on the buttons.
(white is not a colour but the sum of the spectral colours )
The WS3800 has eight buttons by which the multifunctional tiles (display areas) can be switched between the to-be-displayed values (e.g. pressure or rain, min/max values, different outdoor values like dewpoint, feels like, wind or gust, and extra temperature/humidity sensors: single or cycling). Also the background light can be dimmed in two levels or completely switched off.
button | short press toggles between |
---|---|
SET | max, min, alarm, show MAC address |
TEMP | outdoor, feels like, dew point and extra Temp/Hum channels, enter cycling mode |
RAIN | rain rate, event, daily, weekly, monthly, yearly, total |
PRE | absolute, relative pressure |
WIND | wind, gust, direction, 10 min direction |
+ | date, air quality |
- | solar/UV, sunrise-sunset |
LIGHT | display brightness/off |
press and hold button | function |
---|---|
SET | enter setting mode |
SET + LIGHT | factory reset |
TEMP and MINUS (-) | activate WiFi hotspot |
(Also the configuration can be done via the SET button. In setting mode the + and - keys are used to change/toggle between values)
more details see WS3800 manual
the configuration can also be done - as usual with consoles having the local Ecowitt API, via the WS View Plus app and their WebUI. The Ecowitt app can also be used when accessing the local network for its internet access)
WS3900 / WS3910
The WS3910 differs from the WS3900 in that it also has a built-in CO2 sensor. While the WS3800/WS3900/WS3910 can all display the CO2 values of a WH45/WH46(D) sensor, a WS3910 console can display two CO2 values: those from the inbuilt CO2 sensor and the CO2 values of a WH45/46 sensor that is e.g.located in another room. In the display, which changes at the touch of a button, the two CO2 values can be distinguished as follows: the values originating from a WH45/46 have a small reception quality symbol in the display field, the internal values do not have this symbol.
The PM 2.5/10/1 values from a connected WH45/WH46 (D) can be displayed in the bottom left CO2 display tile.
Note that the PM4 readings of a WH46(D) sensor and the T/RH readings of a WH45/WH46(D) sensor CANNOT be displayed on the WS3800/WS39x0 console display. All this their readings together can only be seen on a HP25x0 console or in the WS View Plus app, the ecowitt.net dashboard or in the Ecowitt app. Real-time data only on a HP25x0 console and the WS View Plus app.
The eight buttons on the top panel are used to switch between multiple display locations - There is also an auto-scroll (alternating display) mode for the outdoor temperature/humidity and WH31 Extra temperature/humidity sensors.
The WH41/43, WH51, WH55, WH57, WN34 and WN35 sensors can only be sent to the Ecowitt cloud (or via custom server) but cannot be shown on the display.
If you also want to display these values, you need either an HP25x0 console (on which the display is rather minute for these sensors) or a WN1820/1821 console. See also which sensors displayed on which console
The raindrops and clouds on the weather forecast display flash when a storm condition* is detected. This flashing does NOT indicate that it is raining. However, in the event of prolonged rain and corresponding air pressure conditions, the two may overlap and the drops may flash when it is raining. However, this is only due to the particular situation.
storm condition : a sudden barometer pressure drop for over 3 hPa over the past two hours detected.
(Incidentally, the forecast on the WN1980 also flashes - but only the raindrops there).
The main difference between a WS3800 and a WS3900 console is the screen display layout and the colour.
With the WN39x0 console you have a better overview over the actual rain day situation.
Also, the WS3900 has two rain buttons (RAIN1, RAIN2) to handle the upper and lower portion of the rainfall tile.
button | short press toggles between |
---|---|
SET | max, min, alarm, show MAC address |
TEMP | outdoor, feels like, dew point and extra Temp/Hum channels, enter cycling mode |
RAIN1 | rain rate, event |
RAIN2 | daily, weekly, monthly, yearly, total |
WIND | wind, gust, direction, 10 min direction |
+ | date, air quality |
- | absolute, relative pressure |
LIGHT | display brightness/off |
press and hold button | function |
---|---|
SET | enter setting mode |
SET + LIGHT | factory reset |
TEMP and MINUS (-) | activate WiFi hotspot |
The WS39x0 console is the first Ecowitt display console, where you can see rain rate and daily rainfall amount clearly at the same time without having to press buttons or switches (or need to use a magnifying glass like with the HP25x0 consoles).
the rain rate bar during actual rainfall (show RATE/H) shows the highest rain rate during the actual rainfall
the rain event bar shows the accumulated rain during the time window of the rain event (show EVENT)
[switch with button RAIN1 between display type]
Illustrations: bottom WS3900 - display view and display layout - control buttons - layout examples WS3910 (with inbuilt CO2)
during a firmware upgrade the tile in the lower left of the WS800/WS39x0 consoles (date / air quality tile, CO2, PM …) shows
“OTA.XX” (XX = percentage of completion) - then a restart takes place
Symbols
After a restart (batteries removed, mains cable unplugged and reverse reinstallation and connection - or after a factory reset), the console starts a sensor search, which can be recognised by the flashing of the RF symbol (mini radio mast) in the individual tiles where this is provided (see display layout).
If the corresponding sensor has been found, either because its ID has already been defined or because the console has found a corresponding sensor, the bars (max. 4) for the signal quality (the last four successfully processed data packets) are also displayed for the corresponding sensor.
In the case of sensor arrays, this display takes place in the wind tile. For an external CO2 sensor (WH45/46), this takes place in the tile at the bottom left. Built-in sensors (CO2 for WS3910, indoor temperature/humidity and air pressure) are not displayed.
If the battery level is low or batteries are not inserted, a symbol with a half-charged battery appears in the indoor tile. The same applies to the sensors, where a battery symbol is provided in the layout. The RF symbol with bars is only permanently displayed in the rain tile if a WH40 is connected and the rainfall priority is set to traditional rain gauge.
Reseller name: Froggit WH5000
————————————————————————————————————————————————————————————————-
Special Consoles (RF only - no WiFi)
WH2800 / WH2810 / WH2820 - Ambient WS-2801/2801A
This is more of a “narrow-gauge console” - without reading and displaying wind, rain or sun.
It displays the date and time and the current moon phase. Air pressure and a weather forecast based on air pressure history are also displayed.
Furthermore, indoor temperature and humidity and up to three additional T/RH sensors (type WH31), which can also be placed outside, are displayed under “outdoor”.
Depending on the setting, these change either manually or every 2-3 seconds (cycling - alternating display).
There are min and max displays for temperatures and humidity, which can be reset at midnight (all or none).
It is listed at ecowitt.com under “Thermometer”. It can be operated with up to three temperature sensors, called WH32F (which is a WH31 with DCF-77 receiver).
Power is supplied by a 6 V power supply (mains adapter) or 3 AAA batteries or both as a backup in the event of a power failure. In battery operation, the screen/display is not permanently illuminated. The signal transmission and thus updating of the outdoor temperature/humidity display takes place every 60 seconds.
Ecowitt only offers a 433 MHz model with just one sensor. In Europe, the identical model is also available under the GARNI brand, model GARNI 281, in an 868 MHz version with up to three sensors and changeable display.
Conrad also sells it as Eurochron EFWS S250, 868 MHz.
A station can be legally operated at 433 MHz in Europe. However, you then need extra sensors that transmit at 433 MHz, while the 868 MHz model can use the WH31 sensors of an existing 868 MHz sensor landscape.
Alternatively, the “little man” can receive up to three classic WH31 extra temperature/humidity sensors. It is therefore perfectly suitable as a second console (“for the family” or something alike).
Or used in the bedroom without additional electrical smog from WiFi. This console is purely a receiver. The WH2810 recognises the WH31 sensors that transmit on channels 1, 2 and 7. With and without DCF receiver. With DCF receiver the time is synchronised. A WH31 with built-in DCF receiver with the confusing designation WH32F is supplied.
Attention: there are obviously two different models
WH2800, Ambient WS-2800 with only one (real) WH32 sensor and WH2810, Ambient WS-2801/2801A with a maximum of three WH32F (=WH31 type) sensors.
The Ambient WS-2801 cannot cycle the temperature display of the max three WH31 type (Ambient WH31M) sensors, whereas the Ambient WS-2801A has the cycling/scrolling feature. The Ambient versions transmit at 915 MHz.
Reseller version: GARNI 281, Conrad Eurochron EFWS S250, 868 MHz
————————————————————————————————————————————————————————————————-
HP3000 - Ambient WS-3000
The HP3000 is not part of the official Ecowitt portfolio, however, it can be ordered on demand via the mother company Fine Offset or purchased from a reseller on your continent. The HP3000 comes as a 868 MHz and 915 MHz model. It's more of a temperature/humidity surveillance system than a real weather station.
The HP3000 monitors and graphs up to eight wireless remote sensors (WH31 extra temperature sensors) at the same time. The comprehensive data logger includes a TFT full color display with graphing and monitoring of temperature, humidity, dew point, and heat index. You can view channel 1 temperature, dew point or heat index from the display. You are also able to monitor up to 8 channels at the same time, using imperial or metric measures. This includes minimum and maximum temperature and humidity display with an easy reset option.
High and low alarms can be set for any of the measured parameters; audible and visual alarm will sound when a value is out of range. The sensor search mode allows you to re-sync sensors without removing and re-inserting batteries. Optional temperature and humidity calibration is provided for the utmost accuracy, although the measurement can be adjusted from the console to calibrate to a known source.
The HP3000 also includes PC software for data analysis, console programming, and easy data extraction from the optional micro-SD card.
In Europe the HP3000 is sold as a 868 MHz model by the reseller ELV under the brand dnt as RoomLogger Pro with a black housing.
Reseller version: MISOL WS-HP3001, Froggit DL5000
————————————————————————————————————————————————————————————————-
One-sensor consoles (RF only - no WiFi)
console | related sensor | remarks |
---|---|---|
WN0290 | WH41/WH43 | one WH41 or WH43 only |
WN0291 | WH51/WH51L | one WH51 only |
WN0295 | WH45/WH46 | PM1 and PM4 with WH46 not shown |
WN0298 | WH31/WH30/WN36 | up to eight WH31 family sensors |
WH5360 | WH40 |
WN0290 | WN0291 |
---|
WN0295 | WN0298 |
---|
WH5360 |
---|
————————————————————————————————————————————————————————————————-
4. Sensors
arrays
for further details on the different sensor arrays see also more on sensor arrays
for reseller (clone model) names see brand model translation table
————————————————————————————————————————————————————————————————-
the power supply of sensor arrays
the sensor arrays have several levels of power supply: solar panel, super-capacitor (sort of a rechargeable battery) and batteries (+ external power supply: WS80/WS90). Exception WN67: batteries only.
During the day with sufficient solar exposure the solar panel will run the array. If there is more power produced than needed, the super-capacitor (haptic array [capacitor] at the ecowitt.net dashboard) display for a WS90) will be charged up to 5.3 V in order to provide power duin the night and for low solar exposure. If due to unfavorable weather condition (or a defect) the super-capacitor expires, the backup batteries are used.
(the WS80 power status would be displayed as “sonic array”, the WS69 as “Sensor array”, the WS68 as “Wind Sensor”, the WS85 as “Haptic 3-in-1” - super-capacitor info is only available for a WS85 and a WS90 array)
When you have a WS80 or WS90 and have an external power supply (12V, 1A) connected, the complete array is running via the external power (plus, in winter, the heater)
————————————————————————————————————————————————————————————————-
how to reset an outdoor sensor array
it can happen that the outdoor array stops transmitting data - either all data or only those of some sensors
(e.g. no more temperature/humidity data but wind and solar data is still reported)
before thinking of replacing sensors or parts of the array or even the whole array, a reset may get it back working again
this applies to all Fine Offset manufactured outdoor arrays:
Ecowitt: WH65, WS69, WS68, WS80, WS85, WS90 and WH24 (legacy)
Ambient: WS-2902A,B,C,D-array, WS-2000/4000/5000-array, WH24-array (for WS-1965 array only remove batteries for hardware reset)
Froggit: WH3000SE, WH4000SE, DP1000, DP1100 (for WH3900 array just remove batteries for hardware reset)
there are two types of resets like with a computer:
- restart or warm reset (warm because the hardware continues running)
- shutdown and power off or cold reset (the device will be made powerless and hardware powers up again completely)
- just means to press and hold the reset button for > 5 seconds and release (in some cases your have to insert the open end of a paper clip)
- is more complex
- remove the batteries
- cover the solar panel tightly with black tape - or take the array to a dark room - wait until the LED stops blinking, can take up to 72 hours
- re-insert the batteries and remove the black tape if you used it
1. is also called soft(ware) reset and 2. hard(ware) reset,
because this is what is done, like the restart while still running or shutdown and new start of a computer
————————————————————————————————————————————————————————————————-
WH24 ("the boat")
the “first” wireless (RF based) outdoor array sold by Fine Offset in the early days of private weather stations - still quite a few are running these days. It was sold with the WH1080 console, predecessor of the WS2320 console which came with a USB interface and software.
The old WH24 (Ambient WS-1000/1001/1002) uses a different wind measurement method and has a different funnel surface size for rain readings.
While the consoles with the Ecowitt Gateway API (GW1x00, GW2000, WN19x0, WS3800/WS39xx) have a compensation switch for a WH24 in their device settings, the HP25x0 and HP350x consoles don't.
Here one has to use different gain factors for WH24:
wind gain: 2.17, rain gain 1.18
If you want to use the new WH65/WS69 with an old WH1080 (Ambient WS-1000) console,
the gain factors are: wind gain 0.46, rain gain 0.85
the modern WiFi consoles cannot tell the difference between a WH24 and a WH65/WS69 or WN67 when receiving their signals. The firmware still identifies them internally as WH24.
—————————————————————————————————————————————————————————————————
WS69/WH65
this sensor array is available with identical technology as a 2-wing and 3-wing version. The different designs are often referred to as I (Two-Wing) shape = WS69 or Y (Three-Wing) or osprey shape = WH65. The array includes sensors for wind (speed and direction), rainfall, light (solar radiation, UVI), temperature and humidity. The solar panel contained in the sensor supplies the energy for the normal operation of the sensor and fills an internal supercapacitor, which provides the power supply overnight. The two AA batteries are only used when the capacitor's capacity is exhausted. Battery life of one to two years should therefore be possible.
With the BP0001, an external battery pack is available in which the batteries are housed in a box 10 metres from the actual sensor. This allows the batteries to be changed without removing the sensor from the mast (or having to climb up).
The rain gauge of the sensor array measures in 0.254 mm3 (0.254 mm/m2 precipitation) steps, which are displayed by the console as sequences of 0.2 and 0.3 mm. Therefore, there is a display error of 1.26 % or 0.04 mm in the console display. When the rain values are transmitted by the console, the values are forwarded correctly, without rounding loss, in inches.
The transmission interval is 16 seconds.
The change in design comes from the observation that with the Y-shape there is more mutual disturbance by turbulences between the cups and the direction indicator than with the I-shape.
There are also earlier versions of the WS69 (I-shape), where the cups are below and the direction arrow above (i.e. opposite to what is shown in the picture)
If you want to use a WH65/WS69 combination sensor with an old HP1080/WH1080 console, you have to change the calibration for wind and rain measurement (analogue to the WH24, see there) (as the cups rotate faster and the rain funnel surface is larger than with a WH24, for which the WH1080 console is originally programmed):
Wind gain 0.46, Rain gain 0.85 (“gain” stands for calibration factor)
Ecowitt have developed a specially protected version for the T/RH sensor of the WS80/WS90/WS69/WH65 sensor arrays to protect it against exposure to salty air (e.g. near the sea or in the vicinity of salt deserts, North/South America). This applies only to the new hardware version with plug-and-play sensor. (See picture of WS80)
(Attention: due to the design, this sensor is available in two different versions for the WS90 and the other sensor arrays)
Since June 2024 the WS69 is delivered containing the salty air protection Temperature/Humidity sensor.
The WS69 should not be confused with a (n old) WH14 array which is still sold with old stations for the resellers to empty their stock of shelf-warmers. Even though it looks the same from the outside, the array cannot communicate with the modern Ecowitt consoles (or more precisely speaking the consoles do not understand the array transmissions). The WH14 uses a different modulation technique (ASK = amplitude shift keying) for the transmission from the modern consoles (which use FSK = frequency shif keying). It can only be distinguished by the array name on the underside of the housing where WH14 is shown.
there are spare parts available at https://shop.ecowitt.com for the different sensors:
- the temperature/humidity sensor (two versions for the older and new hardware revisions)
- the funnel
- the anemometer body
- the wind direction indicator (arrow)
- the wind cups
- the whole rain bucket/temp/hum portion
- the whole wind reading portion
- bird spikes for the rain funnel
the spiral offered as protection agains debris (e.g. leaves) for the WH40 can also be used in the WS69 funnel.
for the new WS69 hardware revision you can order
- a pluggable SHT40 sensor for T/RH (sold as WS80 accessory)
- a pluggable SHT35 sensor for T/RH (extra precision)
- a pluggable SHT35 sensor with sea salt protection (sold as WS80 accessory)
(attention - the salt protected sensor for the WS69/WS80 arrays is the same; the WS90 has a different size)
If the supercapacitor of the WS69/WH65 array fails, there is a simple and efficient repair option for hobbyists proposed at:
WH65/WS69 super-cap repair
For details regarding the sensor specifications see below
sensor array specifications
since June 2024 all new WS69 are delivered with the salt protection T/RH sensor version !
reseller product name: Froggit WH3000SE (Y), WH4000SE (I); GARNI G4INT, Ambient WS2000-ARRAY (WH65), ProTECH WS7IN1S (WS69)
———————————————————————————————————————————————————————————-
WN67
The WN67 is a “leight-weight” version of the WS69.
It is basically a WS69 without a solar panel and without a solar sensor.
It is therefore battery-operated. There is a battery enclosure with a 10 m cable available to avoid having to take the outdoor array down from a mast (or climb up) every time the battery needs to be changed.
the enclosure can be found as a single item at https://shop.ecowitt.com under “Accessories for WS69”
The WN67 is sold as a station package together with the WN1900/WN1910 consoles. The enclosure could also be used with a WS69 (I-shape), but not with a WH65 (Y-shape) !
Froggit sell the WN67 together with the WN1910 console as WH3900 station (which now becomes a naming clash with the new Ecowitt WS3900 consoles)
The outdoor array sold with the Ambient WS-1965 is the WN67 array (no solar panel, no solar sensor).
It identifies itself as WH65. Therefore the WS-1965 console can also be used with a WH65 (WS2000-ARRAY).
———————————————————————————————————————————————————————————-
WS68
the Ecowitt 5-in-1 sensor array for wind, gusts, direction, solar radiation, and UV readings.
like its siblings it has a solar panel and an inbuilt supercapacitor to store energy for the operation over night or with low solar exposure.
It has a AA type backup battery.
It is a classic cup anemometer and is meant for operation with individual sensors.
The RF transmission interval is 16.5 seconds.
reseller product name: Froggit DP300
———————————————————————————————————————————————————————————-
WS80
The 6-in-1 sensor array possesses an ultrasonic anemometer. In addition to wind speed, gust and direction, it also measures light (Solat radiation, UVI), and outdoor temperature and humidity.
The transmission interval of the array is 4.75 seconds.
Unfortunately, a battery pack is not available for this sensor (although this is hardly necessary in our Central European latitudes, apart from narrow Alpine valleys and the like, as the supercapacitor fully charged by the solar panel can operate the combined sensor for up to three days without recharging. Conditions in which sufficient recharging due to lack of solar exposure is not possible and the batteries have to be used are very rare here. This is certainly different in Northern Scandinavia or similar locations in North America or Russia with polar nights. The newer models (type 3) can also be operated entirely with an external power supply (see below). ).
However, an extra power supply unit (12 V, 1 A) with a 10 or 20 m supply cable is available as an accessory, which can be used to supply a thermostat-controlled heater that ensures operation of the ultrasonic sensor even at temperatures below freezing point. A cable with the coupling for the supply line is led out of the sensor. The external power supply for the WS80 and WS90 is identical.
with the newer WS80 models (type2 and type 3 - see below) the T/RH sensor can be easily exchanged by plugging in/off, be it to exchange a defective sensor, be it to upgrade the factory state SHT31/SHT40 sensor by a SHT35 extra precision sensor, or be it to use a sea salt exposure protected instead of a normal one.
In newer WS80 models, which were delivered by Ecowitt from May 2022 on, the power supply has been extended from the heater (as with the WS90) to the entire sensor array, i.e. the station runs on the external power supply when the supercapacitor charged by the solar panel is exhausted. The new model is not recognisable from the outside. You would have to dismantle it to know whether the model you have bought is already a newer one. (see below)
WS80 hardware revision by T/RH sensor plug: type2 - red ring/black type3 - blue
One phenomenon in this context is that when the power supply unit (new hardware) is connected, the battery voltage is displayed lower than it actually is. When the mains supply is disconnected, the original (actual) voltage/capacity is displayed again. The background to this is that in order to prevent battery voltage being used/consumed during mains operation, the system is fooled into believing that the battery voltage is lower.
Original Ecowitt explanation: “Yes, this is normal as your heater power supplies to the power for the device of ws80 also. The heater power cuts off the battery voltage, and this lead to a lower battery voltage as the battery power supply is being cut off now for battery power consumption saving reason.”
This applies analogously to a WS90 sensor array.
The newer versions of the WS80 (WS85/WS90 analogously) come with an aluminium mesh on the bottom of the wind reading section - it's a surface tension conditioner layer - a patented cover that prevents the formation of water drops that interfere with wind measurements.
The models currently sold by resellers (Froggit, GARNI, WeatherSpares …) are sometimes still older hardware versions (type 1) and only have a power supply for the heater. Since the end of 2022, this has changed and the new hardware (type 3) is now being delivered, which can also be operated completely via a power supply unit - not just the heater.
However, Froggit currently (October 2023) offers WS80/DP1000 spare parts without mounting accessories, all of which are older models. So be careful if you think you can replace an older model with a newer one! The newer model can be recognised indirectly by the fact that the accessible outdoor temperature/humidity sensor located in the radiation shield can be replaced by simply pulling it out/inserting it (as in the WS90) and has a bluish plug end (type 3). Old is either black at the plug end (type 2) or has only one cable leading inwards (type 1). The protection can be removed with two Phillips screws. (Type 2 WS80 sensor arrays produced after April 2022 can also be operated completely with an external power supply - however, they cannot be distinguished from those produced before April 2022 by a layperson. - One would have to open the main housing and check the mainboard (PCB) for the date printed on it.)
The heater is thermostate triggered and switches on at 0° C/32° F provided the external power supply is connected. It doesn't run constantly but only in intervals their length depending on how much the temperature has dropped below 0° C. When the temperature rises again above +3° C, the heater switches off.
Meant to allow for the ultrasonic wind measurement at low and very low temperatures, it has an impact on the outdoor temperature readings - a deviation up to 4° C/4° K has been observed.
On the other hand, the heat produced is not enough to melt snow or ice which have accumuluted on the sensor array top. Snow has to be removed manually, e.g. with a brush or broom. Otherwise the solar readings are obstructed and the supercapacitor is kept from being charged by the solar panel. Under such condition the sensor array will have to run on its backup batteries.
All the heater related information also applies to the WS90 array.
for firmware upgrades of the WS80 see WS80/WS90 firmware
since June 2024 there is also a battery pack for the WS80/WS90 sensor arrays available with a 10 m cable
this can become interesting for users who don't use the external power supply but run into battery issues due to not sufficient solar exposure - or who cant use it for running the whole array because it's still a type1 or early type2 model (see above).
maintenance
The provided solar panel charges a super-capacitor on the WS80. In normal conditions (solar light intensity
over 20klux and lasted longer than 4 hours), the super-capacitor peak voltage should be above 3.5v and lower than 5.5v. Please check regularly - every six months recommended - the top part of your WS80 and make sure it is free from dust coverage. Use a brush to clean up the surface for higher solar charging efficiency.
reseller product name: Froggit DP1000, GARNI G095HA, Ambient WS5000-ARRAY
———————————————————————————————————————————————————————————-
WS85 ("Essence3")
in fact, the sensor name is WS85 -
Essence3 is the WS3802 station consisting of a WS3800 console, the WS85 Rain & Wind sensor and a WH32 outdoor T/RH sensor
the WS85 is supposed to be a 3-in-1 outdoor sensor - for wind and rain only
it has a solar panel
it will not have a solar sensor
the rain gauge is that of the WS90
no heating or external power supply available
The WS85 is basically a low-cost version of the WS90.
it definitely needs a WH32(-EP) outdoor T/RH sensor as the array portion of the WS90 housing used for the WS85 for T/RH has been sacrificed for allowing the side mounting
so the housing design is new (“WS90 minus T/RH”) and the PCP has got a new chipset (which one to be found out once a sample is available)
The WS85 is supposed to be OTA firmware upgrade enabled.
Latest information shows that at least at the sales start, the WS85 won't come with the OTA upgrade capability yet. A later implementation is being discussed.
As one can see from the pictures, there are two mounting options available - side-mounting or stand-mounting
The base bracket allows for plugging in for both options.
in the WebUI the WS85 is already visible on the SensorsID page (FW WS3800/WS3900/GW1200 1.3.0, GW2000 3.1.3, HP25x0 1.9.6 …)
once a WS85 is available, WS View Plus (V. >= 1.0.49) will recognize it and display it on the sensorsID page of the supporting consoles with local Ecowitt API.
when you have more than one console/gateway which support the WS85, make sure you go through the registered sensor IDs for all of them and disable the WS85 where you want to have the readings from another anemomter or piezo rain readings from another WS90. The cosnoles will pick up the WS85 signal otherwise and replace the other wind/piezo rain readings by the WS85 readings ! (–> sensor hierarchy)
the WS90 rain gauge accuracy suffered from occasional water accumulation on the sensor top leading to underreading the rainfall amount. With the WS85 the steepness of the slope from center to periphery was increased to allow the water to flow off in spite of its surface tension.
this station will be the WS3802 or “Essence3”
the idea behind the name Essence3 seems to be that the WS3802 station consists of the three primary (“essential”) weather observation sensors: Wind, Rainfall, Outdoor Temperature and Humidity.
Of course, the WS85 can also be combined with a WS3900 console instead of a WS3800 - these are the WS3902 and WS3912 stations.
(for the stations the last number used follows usually the following scheme depending on which sensors/array are included: 1=WS69, 2=WS68, 3=WS80, 4=WS90, 5=WH31 - the WS85 seems to break this rule)
a peep under the hud
for more information about the WS85 see Reviews
for an explanation of the haptic/piezo-electric rainfall detection, WS90 rainfall detection
the WS80/WS90 battery pack also works for a WS85. Mounting at the sensor end like a WS90.
It appears that the WS85 has inbuilt only one supercapacitor whereas the WS90 has two (whether they have the same capacity has still to be figured out). As a result the discharge of the WS85 supercap is visibly faster/more than that of the WS90. Ecowitt promise that the WS85 can run on supercap only for around 10 hours (provided no rainfall is taking please whose detection uses additional power)
WS90 left —————————————–WS85 right
(pictures courtesy discord user @WeatherVisionNZ)
click here to see how to determine the installed WS85 firmware version
for those wanting to upgrade/replace the top portion of their WS85, see WS85/WS90 top replacement
———————————————————————————————————————————————————————————-
WS90 ("Wittboy")
Generally available since the beginning of April 2022, this 7-in-1 outdoor sensor measures temperature, humidity, light, UV, wind speed and direction (both ultrasonic) and rainfall (haptic/piezo). Like the WS80 6-in-1 outdoor sensor group, it has a thermostat-controlled heater with an external power supply unit to ensure that the ultrasonic anemometer can also function below 0°C. This is the latest/newest outdoor sensor group from Fine Offset / Ecowitt. Data is sent every 8.8 seconds.
In addition, the power supply can power not only the heater for the rain gauge but the entire station when the supercapacitor, which is charged by the solar panel, is exhausted. Without a power supply unit (12V/1A), the batteries are used when the capacitor is empty. As the WS90 can turn into sort of a battery vampire when it is run without an external power supply, the batteries e.g. in winter due to insufficient solar exposition will not hold longer than two months.
The WS90 is now available individually or together with an HP2551/HP2560 console or the WN1980 console as a package/station (e.g. HP2654 station = HP2560 console + WS90).
The upper sensor section is surrounded by an elastic, tight-fitting silicone cover/sleeve, which additionally protects the USB port (firmware upgrade) from water ingress.
The CAL button on the underside of the anemometer section (top - solar and rain, centre - wind, bottom - temperature/humidity) is used to reset the anemometer to a zero baseline if required. If the anemometer displays values even when there is no wind, the WS90 must be placed in a wind-free environment (indoors, cardboard box) and then the CAL button pressed for a few seconds. Next to it is the button labelled RESET for re-initialising the entire sensor group (but without wind calibration). The north arrow (important for determining the wind direction despite the round design) is located above the battery port. The screw of the battery port should be orientated to the north.
Ecowitt has developed a specially protected version for the T/RH sensor of the WS80/WS90/WS69/WH65 sensor arrays to protect it from exposure to salty air (e.g. near lakes or in the vicinity of salt deserts, North/South America). Applies only to the new hardware version with plug-and-play sensor. (See picture of WS80)
(Attention: due to the design, this sensor is available in two different versions for the WS90 and the other sensor arrays)
At the bottom of the wind reading section there is an aluminium mesh - it's a surface tension conditioner layer - a patented cover that prevents the formation of water drops that interfere with wind measurements.
Regarding a DIY power supply and deviating battery voltage display when connecting an external power supply unit:
see the instructions for the WS80 - connections and power supply for the WS80 and WS90 are identical.
A Sensirion SHT40* is used as the sensor for temperature/humidity measurement. However, it can be replaced or upgraded with an SHT35 using an optional upgrade kit with the chip that is also used in the WH31-EP/WH32-EP (EP=extra precision) sensors.
In addition to the battery, the delivery model also displays the charge status of the supercapacitor supplied by the solar panel, which is the main power supply for the sensor group. This is displayed on the ecowitt.net dashboard both verbally and as a numerical value; e.g. LOW / 0.00 V
*) most of the T/RH sensors used also in other Ecowitt sensors are SHT31 based. But don't let yourself get fooled by the numbers. A SHT40 is not really better than a SHT31. It's a different production line of the manufacturer Sensirion https://www.sensirion.ch
the SHT3x line is for industrial use, the SHT4x line is meant for consumer use.
When the heater element in the WS90 switched on to avoid the formation of frost which would impact the ultrasonic readings, as a side-effect, the temperature/humidity sensor housed under the heating plate would be impacted and deviations up +/- 2° C/ 4° F were observed. As a solution a special SHT30 T/RH sensor was built which can compensate these effects.
SHT30 Temp & Hygr with protection filter and compensation function for WS90 only –>
it's an easily user-replaceable sensor (“plug-and-play”)
Also, even though the official picture/design scheme of the WS90 says that the CAL button and the USB port are “for factory use only”, a firmware update of the WS90 can only be done via the USB port.
And a zero baseline for wind readings can only be established by using the CAL button.
Since firmware 1.3.8 the CAL button can also be used to switch off the blue LED which blinks at each transmission interval. Some customers found that irritating and Ecowitt followed their wish for being able to switch the LED off. In order to do so the CAL button needs to be pressed three times with a little gap in between.
ATTENTION: the start-up hardware version of the Ambient WS-4000-ARRAY does NOT have an inbuilt heater (nor can it be run on an external power supply) - therefore wind readings at temperatures below 0° C / 32° F may not be reliable or fail completely
the anemometer heater element of the WS90
the hardware is most likely the same for the WS80 outdoor array.
the haptic or piezo rain sensor of the WS90
the inner life of the top portion of the WS90 - the PCB (printed circuit board) contains the sensor system for rain detection, the light sensor for solar readings and the solar panel and the connected supercapacitor.
WS85/WS90 HW 3.0 - piezo electrode position |
---|
the sensor hardware has changed between the ß-test phase (hardware revision 1.0) and the later public release (hardware revision 2.0). One can see that the half-moon shaped rain/piezo sensor from HW Rev.1 has been doubled in HW Rev. 2. These sensors are there to make sure that a haptic impact on the surface is caused by water and not by something else - an issue the Tempest Weather stations which have also a haptic rain detection system haven't been able to solve until today (February 2024). The Tempest stations are hypersensitive towards vibrations, and vibrations created and transmitted via the mast/pole or sound waves from airplanes are creating false positives. Ecowitt has taken here a different approach which can distinguish between a hit caused by vibrations or by water drops.
How to calibrate rainfall with a WS90
you cannot calibrate the sensor, you have to calibrate how the console processes the data received from the sensor - therefore the calibration is with the console/gateway
use either the WS View Plus app or the WebUI (inbuilt webpage) or with the HP25x0 console inside the console
console / gateway | application | where and how to calibrate |
---|---|---|
GW1000, GW1100, GW1200, WN1910, WN1920, WN1980, WN1820/WN1821, WS3800, WS39x0 | WS View Plus | More –> rain totals –> choose rainfall priority “piezo” –> enter values per tier –> save –> success message |
GW1000, GW1100, GW1200, WN1910, WN1920, WN1980, WN1820/WN1821, WS3800, WS39x0 | WebUI, inbuilt webpage | from the menu: Rain Totals –> choose rainfall priority “piezo” –> enter values per tier –> save –> success message |
HP2550, HP2560 | console settings pages | 1st step: from the menu: Setup (gear wheel) –> More [Setup] choose rainfall priority “piezo” 2nd step –> 3x Setup (gear wheel) –> choose “rain gain” [Setup], enter values per tier –> save –> success message |
The WS90 is set up in a way that five different linear gain factors can be applied for different rain rate tiers.
The accuracy of the haptic/piezo rain sensor is widely discussed and has meanwhile improved from “poor” to “acceptable”. Still, Ecowitt recommend now on their product web page, to use an additional traditional WH40 rain gauge when high accuracy is wanted.
The reasons for the lack of high accuracy are manifold.
A haptic rain sensor has to fulfill certain criteria. It has to record vibrations originating from raindrops. At the same time it has to exclude false positives created by external vibrations from other sources. This the WS90 can manage quite well. A little issue still remains and needs to be resolved: when it rains lightly quite some water remains on the surface due to the water surface tension. When the water doesn't flow off due to wind or stronger rainfall, it affects the continuous reading i.e. it doesn't register additional light rainfall. This still needs to be solved.
Meanwhile Ecowitt have improved the top portion for the WS85 ("added slope").
As per recent Ecowitt statements (June 2024) the recently manufactured WS90 arrays also already have the modified top.
The characteristic line of the rain sensor, especially in the low rain rate area turned out to be best represented by a square or cubic function of the type
y = a * x2 or y = a * x3.
That's what many field experiments by users showed. Only then the linear gain factors provided for the different rainrate tiers make sense.
With firmware 1.3.8 most of the observed issues seem to have been significantly reduced. Still, depending on rain type and accompanying winds, there can be deviations of 2-3 mm.
suggested baseline tier gain factors for the WS90
tier | rain rate | firmware | gain factor | firmware | gain factor | ||
---|---|---|---|---|---|---|---|
piezo 1 | < 4 mm/h | 1.4.3 | 0.72 | 1.4.6 | 0.45 | 1.4.7 | 0.70 |
piezo 2 | >= 4 mm/h < 10 mm/h | 0.70 | 0.70 | 0.65 | |||
piezo 3 | >= 10 mm/h < 30 mm/h | 0.92 | 0.70 | 0.70 | |||
piezo 4 | >= 30 mm/h < 60 mm/h | 1.00 | 1.00 | 1.00 | |||
piezo 5 | >= 60 mm/h | 1.00 | 1.00 | 1.00 |
these factors don't claim to be the ultima ratio, but they can serve as an orientation to experiment with yourself
Ecowitt give the following background information to explain the need for different calibration for different rain rate ranges (tiers):
“Piezoelectric rain gauge working principle: raindrops fall on the sensor's surface so that the monitoring panel produces small mechanical vibration, the vibration of the mechanical stress, and the sensor produces a voltage difference corresponding to the amount of rainfall. *1)
In practice, the measurement of precipitation by piezoelectric rain gauges is influenced by environmental factors such as wind, terrain, and debris. In the case of large rainfall intensity, rainfall intensity can be measured by the piezoelectric rain gauge, but the raindrops landing may have two impacts on the monitoring panel*2) so that the measured rainfall value is larger; for minimal rainfall intensity, due to the vertical momentum is being too small, so that the measured rainfall value is also too small. Therefore, it is necessary to calibrate the piezoelectric sensors for different rainfall intensities depending on the environment in which they are located.”
(strike-through, footnotes and addenda/reformulation by WiKi author for better understanding)
*1) as this vibration could have also been caused by other factors, the panel has also a detector which verifies the presence of water to exclude other sources of vibrations
*2) this means that a large drop can “break” into two pieces and show as two drops even though it was originally only one and therefore being double counted
———————————————————————————————————————————————————————————————–
viewing rainfall from a traditional and a piezo rain gauge synoptically
prerequisites:
1. using a console/gateway with the local Ecowitt API
2. having a WH40 or a WS69 and a WS85 or WS90 connected/registered to such a console/gateway
This synoptical view in the WebUI for an Ambient WS-4000-ARRAY is only possible with a WS-1965 or Ambient Weather Hub IP2 or IP3, provided the WS-4000-ARRAY (WS90) is registered to these consoles/gateways.
———————————————————————————————————————————————————————————————–
How to determine the WS90 (and WS85) firmware version
there are three ways how to determine the firmware version of your WS90 depending on the console you have
- all consoles: hover the mouse pointer over the “Reported xx seconds ago” under the name of your console WiFi firmware name in the top center of your ecowitt.net dashboard
- with a console with local Ecowitt Gateway API: on the sensors ID page of WS View Plus at the very right of the WS90 or WS85 sensor line
- with a console with local Ecowitt Gateway API: on the sensors ID page of the WebUI hovering your mouse pointer over the WS90 or WS85 icon
the cable for the external power supply (running the array, heater) usually hanging outside (your cable can be black or white) can be moved inside the mounting piece and be run inside the pole/mast/pipe (provided it is hollow)
for firmware upgrades of the WS90 see firmware WS80/WS90
since June 2024 there is also a battery pack for the WS80/WS85/WS90 sensor arrays available with a 10 m cable
this can become interesting for users who don't use the external power supply but run into battery issues due to not sufficient solar exposure.
(battery pack and installation are the same for a WS85)
maintenance
Ecowitt state:
The provided solar panel charges a super-capacitor on this WS90. In normal conditions (solar light intensity
over 20klux and lasted longer than 4 hours), the super-capacitor peak voltage displayed on the battery tile from
your dashboard should be above 3.5v and lower than 5.5v. If it is not overpassing 2.5v, please check the top
part of your WS90, and make sure it is free from dust coverage. Use a brush to clean up the surface for higher
solar charging efficiency.
future development
Ecowitt are working on improving the accuracy of the WS90 rain readings, especially in the low rain rate area. A promising approach seems to be to add an optical rain sensor to the existing design to compensate for the shortcomings of the piezo-alone approach for rain amount detection.
as per a recent statement of Ecowitt (02-Jun-2024) the increased top slope between center and periphery introduced with the new WS85 Rain & Wind sensor is now also inplemented in the newly manufactued WS90 arrays.
it appears that not only a stronger curvature/arch was implemented but also the center piece was slightly tilted to prevent residual water.
So that's not a construction defect but a feature !
rain start detection
the WS90 and WS85 now have a rain start detection (detection of first raindrops) implemented. The GW2000 is the first console where this feature is implemented with firmware 3.1.5 - other IoT-enabled consoles to follow.
in the customized server post string, the observation will show as srain_piezo
it can have the status “1” - raining or “0” - no rain
status 1 will be reset to 0
- once the top is dry
- after the amount of water on the top has remained unchanged for two hours
for RTL_433 users: the status bit sits in bit #5 (counted from the right, starting with “1”) in Byte #17 (counting starting with “1”) of the transmission payload.
———————————————————————————————————————————————————————————————–
potential impact of the slope on light (solar) readings
It was suspected by users that it is possible, that with the higher slope end pointing towards South, as the hardware setup (North arrow) may suggest, the slope might have an impact on the light readings during day-start and day-end hours at higher geographical latitudes and low(er) sun position.
During first tests with the higher end of the slope pointing North did not show any impact.
Therefore, for owners of the WS90 with slope before the still to be released elevated light sensor, the positioning of the higher slope end towards North and a correction of wind direction by 180° is recommended.
In addition, Ecowitt will raise the light sensor position inside the array to minimize reading losses due to low solar position even with the high slope end pointing South.
———————————————————————————————————————————————————————————-
For those wanting to upgrade the top portion (slope, solar sensor positioning) the top part is available as spare part or “accessory”
the instructions can be found here: WS85/90 top replacement
reseller product name: Froggit DP1100, Ambient WS-4000-ARRAY
———————————————————————————————————————————————————————————-
WN90LP
There is also a WS90 version with a serial RS485 interface (Modbus) - the WN90LP. As the name tells, it has no solar panel and runs on either batteries only or needs to be permanently powered via the 12V/1A power supply which will also run the heater at temperatures < 0° C. It has an extra inbuilt pressure sensor. (N=no solar panel, L=Line, P=Pressure). Firmware updates are done as with a “normal” (RF) WS90 and the firmware is the same.
Its new data provisioning interval (data refresh interval for signal transmission)* is different for different observation types:
rainfall: every 8.7 seconds
wind speed: every 2 seconds
voltage: every 10 minutes
(a WS90 updates all this data every 8.7 seconds)
Querying the sensor more often (one could query via the RS-485 interface every second) will only get “stale” data from the last provisioning.
*) some people don't like the term “transmission” here, even though (signal) transmission is not reserved for over-the-air data transport/delivery but is media independent (can be via cable, optic fibre, air, space …)
It comes with a 2 m 4-wire cable (5-15 V).
V_heater (red) — 12 V power supply
GND_heater (black) — GND power supply
Data_A (green) — RS-485 adapter A
Data_B (white/yellow) — RS-485 adapter B
There is also a 10 m cable available for power supply/data communication. 5 - 15 V.
———————————————————————————————————————————————————————————-
single sensors
direct links | |||||||
---|---|---|---|---|---|---|---|
WH32/WN32 | WH32B/WN32P | WH31 | WN30 | WH31/32-EP | WN34 | WN35 | WH40 |
WH51 | WH51L | WH55 | WH41/WH43 | WH45/46 | WH46D | WH57 | WH54/LDS01 |
for reseller (clone model) names see brand model translation table
———————————————————————————————————————————————————————————-
WH25
the legacy TH&P sensor of older Fine Offset weather stations (like a WH1080) is the WH25.
the modern WiFi consoles cannot distinguish between the signal of an old WH25 TH&P sensor and the new WH32B/WH32 indoor/WN32P sensor.
Internally the firmware still identifies them as WH25, be it a real WH25 or a WH32B.
———————————————————————————————————————————————————————————-
WH26
the WH26 is the Fine Offset legacy T&H (temperature/humidity outdoor) sensor, the predecessor of the WH32 outdoor.
———————————————————————————————————————————————————————————-
WN30
A temperature sensor for liquids with a remote, waterproof sensor that shares the channels with the WH31/WH31-EP (see there). The cable for the sensor is approx. 3m long - therefore apparently no I2C sensor is used but a thermistor.
The WN30 is now (30.04.2021) finally also available from Ecowitt. The WN30 corresponds to the DP30 at Froggit .
Internally, Ecowitt also lists the WN30 as WN37xN, i.e. WN37AN for the 868 MHz model.
According to our own tests, the maximum measured temperature is exactly 60°C - the display/output is 60°C even at higher temperatures. Ecowitt has confirmed this and argued that there is no accuracy above this value.
reseller product name: Froggit DP30
———————————————————————————————————————————————————————————-
WH31
An extra temperature/humidity sensor for indoor, outdoor or other areas. This can of course also be installed outside in a suitable housing. However, the measured values of these sensors are reported to the software and the weather services as indoor sensors, more precisely as extra temperature/humidity sensors. An SHT30 is used as the sensor.
The specified temperature range of -10°C to +60°C refers to the built-in LC display - it is therefore only ensured that the data is also shown on the sensor display within this range. As the sensor should be housed outdoors in a weather protection anyway, there is no need for a display. The actual measured values are also transmitted outside the specified temperature range.
The transmission interval is 61 seconds.
This sensor can transmit on eight different channels, which are set via small DIP switches under the battery cover. Eight extra temperature/humidity sensors are possible to be registered per supporting console. The WN30 (see above) belongs to the WH31 family and counts towards the channel allocation. The same applies to the WN36 pool sensor (see below) - this one also shares the 8 WH31 channels. The externally recognisable difference to a WH32 sensor (see below) is the presence of the DIP switches and the display of the channel number on the display.
There is a special version of the WH31 with DCF77 receiver, which is offered by dnt as DNT000005 Thermo/Hygro Sensor RF 868MHz. The DCF77 receiver inside supplies the RoomLogg PRO or the WH2800 with the correct time. When used as an additional sensor for GW1000, GW1100, HP2551C, HP3500 - where the station receives the time via NTP - the DCF data is not analysed. Otherwise, these sensors correspond to the “normal” WH31 - i.e. they are processed by the stations like sensors without a DCF77 receiver.
While the dnt sensors with DCF77 can transmit on up to eight channels, there is a reduced version for the WH2800/WH2810 console, the WH31F, which can also receive the DCF77 signal, but can only select three channels. These channels correspond to channels 1, 2 and 7 of the eight WH31 channels.
Whether the station (console) can also receive the time from the WH31 via DCF77 - for example if the NTP server is not available - is unlikely, but still needs to be checked.
A WH31 can be converted to a WH32
Ambient sell a “special” WH31 type of sensor under the name WH51RF as specially designed for refrigerators and freezers.
“The sensor offers flexible placement options such as hanging from a metal wire shelf, mounting on a wall, or simply resting on a horizontal surface. This versatility ensures optimal positioning for accurate readings without compromising storage space or convenience.”
Even though claiming special features, nothing which supports this statement (apart from coming with a hook/hanger and a removable little stand) can be found on their website. The IP rating of the housing is the same as with the normal WH31 sensors.
The housing is Ambient designed - the PCB is Fine Offset manufactured.
The website wrongly claimes that it has a reporting interval of 80 seconds, different from the usual 61 seconds of other WH31 variants.
For more details about temperature sensors in the Ecowitt ecosystem see different types of temperature sensors
reseller product name: Froggit DP50, GARNI 092H (and WH32F with the GARNI 280), Ambient WH31E
———————————————————————————————————————————————————————————-
WH32B/WH32 (indoor)/WN32P
Please do not confuse it with the WH32 - despite the almost identical name! The WH32B (the B stands for barometer) is the remote sensor for temperature, humidity and air pressure for the HP2551C, HP3500 and WH2650/Froggit WH2600Pro WIFI console. At first glance, the sensor looks like a WH32 - but it is intended for indoor use and, unlike the WH32, can also measure air pressure. It is also labelled “Pressure Sensor”. Ecowitt has also recently started using the designation WN32P (P for “Pressure”). The previous designation - from which the name of the battery value in the Ecowitt protocol also originates - is WH25. The new (February 2024) WS3800/3900/3910 consoles also have built-in T&HP sensors, but can also use a separate WH32B/WN32P as an alternative. There can only be ONE T&HP sensor per console which shows as Indoor (even though you can rename it in different consoles, but the display position remains).
Ecowitt now markets the WH32B as the WH32 indoor and the WH32 as the WH32 outdoor, possibly to avoid the confusion that has repeatedly arisen among users. Froggit also sells the sensor with the HP1000SE Pro console, but does not sell the sensor as a separate item. However, it is probably possible to order a replacement on request.
Note: Ecowitt meanwhile allows to optionally switch off the use of the built-in indoor temperature, humidity and air pressure sensors of the HP2560, WN19x0, GW1100 and GW2000 as a firmware option and to be able to use a WH32B/WH32 indoor instead.
Since firmware 2.3.1/3.1.1/1.2.8, the GW1100/GW2000/GW1200 can also use a separate T&HP sensor (WH32B, WN32P) instead of the built-in T&HP sensors.
A WH32B can be converted into a WH31 or WH32
For more details about temperature sensors in the Ecowitt ecosystem see different types of temperature sensors .
———————————————————————————————————————————————————————————-
WH32 outdoor
Temperature/humidity meter for outdoor use. However, this sensor cannot (or can hardly, depending on the location) be used outdoors without a protective housing - it lacks any protection mechanisms against moisture ingress. There can be exactly ONE WH32/WH32-EP in each weather station installation (per console*) (there is only one outdoor sensor defined as such in the Ecowitt world).
Inside the so-called sensor hierarchy it stands on top. This means that the consoles will prefer its readings over all other outdoor T/RH sensors (of a WS69/WH65, WS80, WS90) registered at the same time to the console.
It gives you also the flexibility to more freely choose the location of your outdoor T/RH sensor. The arrays are usually put high up for optiml wind readings.
The values of this sensor for temperature and humidity are preferred by the station; they therefore replace any existing values of a sensor array.
The specified temperature range of -10°C to +60°C refers to the built-in LC display - it is therefore only ensured that the data is also shown on the sensor display in this range. As the sensor should be housed outdoors in a weather protection anyway, there is no need for a display. The actual measured values are also transmitted outside the specified temperature range.
The transmission interval is 64 seconds.
Attention: an unfortunately so-called WH32F is NOT a real WH32 but a special WH31 with DCF77 reception, which was developed for the WH2800/WH2810 console. It is NOT displayed as an outdoor temperature/humidity sensor on any other console, but as an extra temperature/humidity sensor like any member of the WH31 sensor family.
(*GW1200,GW1100/GW1000/GW2000/WH2650/HP2551/HP2560/HP350x, WN19x0, WS3800, WS39x0). The WH2910 (Froggit WH3000SE) and the WH2320E (Froggit WH4000SE) cannot receive a WH32 - they only receive the signals from the WH65/WS69 outdoor sensor group.
the WH32 outdoor/WN32 housing is not waterproof. You need to place it into a protected space or use a shield for protection against the elements - and solar irradiation.
If the sensor is exposed to solar irradiation, you need to use a GOOD (!) and not only good looking radiation shield (or a Stevenson shelter) which is well aired. For passive (= naturally ventilated or aspirated) radiation shields, see Passive Radiation Shields
Some good and better shields only use probes - then the WH32-EP (extra precision) sensor (see below) would be needed.
for tinkerers: A WH31 can be converted to a WH32
For more details about temperature sensors in the Ecowitt ecosystem see different types of temperature sensors
reseller product name: Froggit DP40, Ambient WH32E (end of life - use Ecowitt WH32/WN32 outdoor instead)
———————————————————————————————————————————————————————————-
WH31-EP
An improved version of the WH31 with a more precise sensor. The sensor used here is the Sensirion SHT35, which is more accurate, especially with regard to humidity.
The actual sensor is separated from the sensor housing by a cable (~1m). (See picture of WH32-EP below) Like the WN30, the WH31-EP belongs to the WH31 family and counts towards the channel allocation (maximum 8 per console).
The WH31-EP is often referred to internally by Ecowitt as WN37xS, i.e. WN37AS for the 868 MHz model. This is also printed on the housing. WH37AS may have been relabelled WN31-AS in the meantime. The remote sensor on the 94cm long cable has a diameter of 18mm and a length of 68.35mm. The cable has an outer diameter of 5mm.
———————————————————————————————————————————————————————————-
WH32-EP
The improved version of the WH32 with the more precise Sensirion SHT35 for outdoor use. There can be exactly ONE WH32/WH32-EP in each weather station installation (per console*) (in the Ecowitt world there is only one outdoor sensor defined as such). In contrast to the “normal” WH32, the sensor is located in a probe which is led out of the housing on a cable approx. 1 metre long.
The remote sensor on the 94cm long cable has a diameter of 18mm and a length of 68.35mm. The cable has an outer diameter of 5mm.
(*GW1200/GW1100/GW1000/WH2650/HP25x0/HP350x, WN19x0, WS3800, WS39x0)). The WH2910/WS2910 (Froggit WH3000SE) and the WS2320E (Froggit WH4000SE) cannot receive a WH32 - they only receive the signals from the WH65/WS69 outdoor array.
If you want to operate a WH32-EP (or a WH31-EP, see above) in a professional Barani MeteoShield Pro passive radiation shield (“weather hut”, Stevenson screen), you will find instructions here: https://www.baranidesign.com/faq-articles/2022/8/01/how-to-properly-mount-an-ecowitt-temp-humidity-sensor-inside-the-meteoshield-pro
———————————————————————————————————————————————————————————-
WN34S / WN34L
This is a temperature sensor for liquids (WN34L) and for soil (WN34S). L = liquid and S = soil
The WN34S is a soil temperature sensor in which the actual sensor (NTC) is located in a metal tube that can be inserted up to 30cm deep into the soil. The tube has a diameter of 10mm. Power is supplied by an AA battery, for which a lithium battery is often recommended, as is usually the case with outdoor sensors. The battery is not included in the delivery package - however, a clamp and other mounting material are included.
The current temperature can be read on the display - in °C for the 868 MHz models. The transmitter unit is identical to the WN34L - so this sensor shares the 8 available channels with the WN34L and the output key (tf_chN) and the transmission interval are identical: 77 seconds. The battery values are transmitted as tf_battN in volts in the Ecowitt protocol (–> customized server). The newer hardware revisions have a little switch inside the battery compartment where the displayed unit - °C or °F - can be selected.
A silicone seal in the battery compartment makes this sensor actually appear waterproof (IP65 is the specification) - however, long-term experience is still lacking. The measuring range is specified as -40 - +60°C - so use in most latitudes(Europe, North-America, Australia) should be assured. After pressing the tube in the ground, the setup is surprisingly stable. The WN34L measures the temperature in liquids, but can probably also be used to measure the temperature in air. The actual sensor (NTC) is attached to an approximately 3m long cable. Clamp and mounting material are included, but not the AA battery required for operation.
Interestingly, the WN34 sensors are not listed in the firmware (and thus in the internal GWyx00 API) as soil temperature sensors, as perhaps expected (the WH51 sensors are listed as soil moisture sensors), but as user-defined temperature sensors. [Details see Ecowitt Gateway API]
For more details about temperature sensors in the Ecowitt ecosystem see
different types of temperature sensors
Reseller product name: Froggit DP35 and DP150, Misol WN34 CS/L.
———————————————————————————————————————————————————————————-
WN34D
The WN34D is a special version of the WN34L with an extended measuring range: -55 °C to +120 °C. Cable length 1 m (WN34L 3 m) Cable colour blue (WN34L grey/beige)
Will be distributed by Ecowitt from the end of September (22 September 2023). The sensor installed in the WN34D is no longer a thermistor, but a Onewire sensor DS18B20.
For more details about temperature sensors in the Ecowitt ecosystem see
different types of temperature sensors
———————————————————————————————————————————————————————————-
WH35
This is a leaf moisture sensor for 8 channels.
The WN35 leaf moisture sensor is like an artificial leaf and measures the moisture (in per cent) as a result of precipitation/dew.
Up to 8 (!) leaf moisture sensors are possible - each working in its own channel. Power is supplied via an AA battery.
The transmission interval is 79.5 seconds.
It can also serve as an early rainfall detector.
reseller product name: Froggit DP10, Ambient WH51LW, Misol WN35CN
———————————————————————————————————————————————————————————-
WH36
This is a waterproof (IP68) floating pool temperature sensor.
The sensor has been available from Ecowitt since June 2022.
It contains a built-in and non-replaceable battery (presumably due to the waterproofness) with a service life of 3-5 years.
The sensor shares the channels with the WH31; the transmission interval is approx. 60 seconds.
reseller product name: Ambient WH31PF
———————————————————————————————————————————————————————————-
WH40
The rain gauge for operation with individual sensors.
One measuring spoon emptying corresponds to a rainfall of 0.1 mm/m2 (or litres/m2). (In comparison, one measuring spoon emptying corresponds to 0.254 mm/m2 for the rain gauge of the WH65 sensor group). The measurement is therefore taken in 0.1 mm increments (WH65: 0.254 mm increments). Strictly speaking (due to rounding errors when converting from inches to the metric system), a tipping of the measuring spoon reported as 0.1 mm corresponds to 0.102 mm - therefore a calibration of 1.022 should be set in the console when using metric units.
The transmission interval is 49 seconds. The original hardware revision cannot send the battery value - so an empty battery is only detected when the sensor is no longer sending data. It only sends a constant fake value of 1.4 Volts.
The devices sold by Ecowitt from summer 2021 are now able to transmit the real battery level. (Details –> table below)
Those devices sold under the Ecowitt label show the hardware revision on the battery door.
Due to the design (very flat and large rain funnel and a very low edge of the funnel), measurement losses due to splashing occur in heavy rain and/or in combination with strong winds (overblow loss).
A 5-6 cm (~ 2 inches) high attachment created with a 3D printer (or the attachment of rigid plastic wrap of the same height) significantly improves the measurement result. (see below)
Inspired by the 3-D model, Ecowitt now offers a 2 1/2 cm high attachment as an accessory, which is mounted using the fastening strap of the bird repellent attachment. If you do not already have the bird repellent, you must order both.
Ecowitt have meanwhile conceptualized a new funnel with a +/- 5 cm rim which also contains holes to insert bird spikes at the top end of the rim.
the new WH40 funnel (November 2024) –>
the height from the rim edge to the outer funnel ground is 46 mm
(4.6 cm, 1.65 inches)
holes for bird spikes are available, diameter 1.8 mm
(this corresponds to the smallest standard bike spoke diameter
[1.8, 2.0, 2.3 mm])
the included bird spikes have a length of 9.6 cm/ 3.8 in
for sale since 27-Dec-2024
with the higher rim wind blowover and splash/spray losses will be significantly reduced.
such mechanisms are also used in professional rain amount determination. Picture source Wikipedia
The new funnel (accessory) with bird spikes (accessory) (December 2024)
all new WH40 will be delivered with the new funnel - bird spikes will be included
the new WH40 will also come with an UV resistant housing, the same material as the WS90
prospective sales date: mid- to end-January 2025 - before the start of the New Chinese Year [29-Jan-2025]
the highest processable rain rate of the WH40 is ~ 360 mm/h, one measuring spoon emptying per second
the rain rate is determined/averaged over 10 minutes with a resolution of one minute
(with the rain gauge of the WH65/WS69 it would be 900 mm/h (0.254 mm per measuring spoon emptying))
By the way, there are always questions about the definition of a
rain event.
The Ecowitt definition is: “Rain event is defined as continuous rain, and resets to zero if accumulated rainfall is less than 1 mm (0.039 in) in a 24 hour period.”
Continuous rain ends when there is no further rainfall registered within one hour.
A rain event therefore ends if no rain has fallen for one hour since the start of rain and accumulated rainfall >= 1 mm and it has not rained more than 1 mm within the following 24 hours
attention - the definition used by AWN for rain event is different from the above definition, but what is shown on the console display goes by the above definition
reseller product name: Froggit: DP80, GARNI G097R, Ambient WS-5000-RAIN
attention :
it has been repeatedly reported that the WH40 signal becomes unreceivable when the battery compartment points towards the receiving console/gateway. Please make sure the battery compartment points away from the WH40 - console line.
some details on the rain information transmission
the rainfall information transmission contains a 2-byte counter which starts at 00 and ends at HEX FFFF (65,535) where it will be reset to 00 (after having counted 6,553 mm or 6.55 m3 rainfall).
The console saves the counter information in the RAM and determines the rainfall by the difference of the last saved counter and the actually received counter. Like this missed transmissions will be caught up with.
During a console reset/reboot/power cycle the counter information gets lost ⇒ each reset can potentially produce an error of 0.1 mm rainfall (= losing 0.1 mm) - which can be compensated by manually adding 0.1 mm to the daily/weel/monthly/yearly rain totals after a reboot.
———————————————————————————————————————————————————————————-
WH41 / WH43
Air quality sensor for outdoor use. It has 2 AA NIMH rechargeable batteries that are charged* by the integrated solar panel. In the winter months in northern European latitudes, it must be assumed that the WH41 must be charged manually (via a USB cable) every fortnight. The sun is then not sufficient to charge the batteries.
(*) one should better say: whose charge is maintained for a longer period - even in summer time in Northern European Medium latitudes (45° - 55° North) the solar panel cannot fully maintain the charge and a manual recharge becomes necessary after 6-8 weeks - either via the micro-USB charging port between battery compartment and housing wall or via already externally charged batteries)
Although the model is labelled for outdoor use, it can of course also be operated indoors as long as the console can receive the signal from the sensor.
The sensor used originally is a Honeywell HPMA115S0-TIR has been meanwhile replaced by a CPM2005 from Senseiot or most recent a Plantower model.
The transmission interval is 10 minutes - when power connected via the USB port the interval is 60 seconds.
Ambient Weather has produced a very helpful document on cleaning. The text is only available in US-American. However, with the Google Translator or better the German https://www.deepl.com translation service, a comprehensible translation should be possible. Otherwise, the pictures alone may also help.
see PM2.5 maintenance
There is also an alternative cleaning instruction from a weather station owner from the Netherlands in wxforum.net with lots of pictures (also in English): https://www.wxforum.net/index.php?topic=44019.msg448034#msg448034
The sensor is sensitive to high humidity when/where minute droplets will be detected as false positives.
Newer models of the WH41 have the USB charging connector also outside like the WH43/45/46 - the connector is micro USB. The newest models should have a USB type C socket (EU regulations)
The WH43 is the indoor version without solar panel and there the micro-USB port is accessible from outside.
(This port will in future also be USB type C only)
1. RF indicator
2. USB charging port (micro USB/USB type C)
more WH41 information:
Ecowitt write on their website:
“The sensor is sensitive to liquid droplets - rain/fog/sprinkling. When the Dew Point is close to the outdoor temperature(T - D < = 2°C), the PM2.5 reading will be very high (which is not the real condition). If (you) mind, please don't purchase.”
A DIY setup (plexiglass) to protect against direct rainfall still providing enough airflow has been proposed - see example Another “hack” sometimes used is to permantently connect a USB cable with a 90° angled micro-USB plug, drill a hole into the black housing portion and the covering lid (put some silicone seal around the outer hole) and keep the WH41 permanently charged, be it with a powerbank, a solar panel or a power-grid connected charger.
One more “hack”, which became necessary at very low temperatures (below -18° C) in Canada where the batteries froze, is to replace the batteries by a supercapacitor. see using Supercapcitors to winterize WH41 and improve cold temperature performance
reseller product name: Froggit DP200, GARNI 080Q, Ambient PM25 OUTDOOR
———————————————————————————————————————————————————————————-
WH45 / WH46 / WH46D
Improved 5-in-1 air quality sensor for indoor use. Looks very similar to a WH43 on the outside (same housing, same miniUSB charging port), but combines 5 sensors. In addition to PM2.5, it also measures PM10, temperature*, humidity* and CO2 levels. Although 2 AA batteries can be inserted, we recommend using a USB power supply unit. In battery operation, the batteries run out very quickly - despite the significantly reduced transmission frequency.
WH45 manual
The transmission interval is 60 seconds with an external power supply. If the WH45 is operated with batteries, a measurement and transmission to the weather station console only takes place every 10 minutes.
*) the temperature and humidity readings are NOT shown as indoor temperature and humidity; this is reserved to only one sensor.
For more details about temperature sensors in the Ecowitt ecosystem see
different types of temperature sensors
The WN46/WH46 (release date March 2024) is the successor of the WH45. It's now a 7-in-1 air quality sensor and provides in addition to the WH45 also PM1 and PM 4 readings.
WH46 manual
All these readings are visible in the Ecowitt dashboard, the Ecowitt app and the WebUI with live data.
They can also be seen in the WS View Plus app as it reads the data API via the the local Ecowitt gateway http API and on the HP25x0 console display. The local Ecowitt gateway API (“telnet API”) will no longer be further extended as per Ecowitt, but the WH46 PM1/PM4 data are still contained, even though not officially documented.
A portion of the readings (CO2, PM1. PM2.5, PM10) can also be viewed in the date tile of the WS3800/WS39x0 consoles.
Recently (August 2024) a WH46D, D for Display, has been announced. The WH46 7-in-1 sensor array with an integrated LCD display with touchbuttons which like this can also be operated independent of a console/gateway. The registration with a console of the same radio freqeuncy is of couse also possible and when posting to ecowitt.net it will be recognized as an AQIN (air quality indoors) sensor like a WH45/46.
the WH46D manual is available here.
the WH46 will no longer be produced and will be completely replaced by the WH46D
the WH46D is out for sale since 14-January 2025
The only console on which all the WH45/46(D) sensor values can be seen/shown are the HP25x0 console (for WH46(D) with device firmware >= 1.9.5). The values are displayed in a cycle mode in the 3rd line under the outdoor temperature and wind readings (left page half). The T/RH readings can be seen in static or cycling mode on the right page half in the area where also the indoor and WH31-family extra temperature sensors are displayed.
The WS3800/WS39x0 console do not display the PM4 and T/RH readings of the WH46(D).
Beyond HP25x0 and WS3800/WS39x0, the WH46(D) readings can be seen together only in the WS View Plus app (for consoles/gateways with the local Ecowitt API), the ecowitt.net dashboard or in the Ecowitt app, the latter being a copy of the ecowitt.net dashboard for smartphone and tablet viewing. The same applies to the T/RH readings of a WH45.
reseller product name: (WH45) - Froggit DP250, GARNI G083QC, Ambient AQUIN
———————————————————————————————————————————————————————————-
WH48
The WH48 is an eight channel Ambient only CO2/T/RH (3-in-1) sensor and not yet published by Ambient so far (November 2024). It will come in a new housing and an integrated display. The Ambient consoles (WS-2000/4000/5000; AWN Weather Hub [IP3] and ObserverIP2 [IP2]) will be able to register up to eigth of the new WH48 sensors. Ecowitt consoles won't be able to process the WH48 transmissions. With AMBWeatherPro firmware >= 5.1.7 they can be posted to AWN.
Similar to the Ecowitt WH46D (7-in-1 air quality sensor with display) it can be used stand-alone without being connected to a console/gateway.
———————————————————————————————————————————————————————————-
WH51 / WH51L
The soil moisture sensor reports the moisture in the soil with a value from 0 (dry) to 100 (liquid).
The transmission interval is 70 seconds. However, this transmission interval is adaptive - in the event of a major change within a short period of time, the transmission interval is reduced to 10 seconds and set back to the standard interval once the value has levelled off.
The exact procedure is as follows:
There is a so-called transmission boost, which occurs when the humidity suddenly changes (usually upwards). The system then switches to a 10-second transmission interval, with seven (7) transmissions every 10 seconds. An internal counter (transmission boost) then counts down from “7”. When “0” is reached, transmission resumes every 70 seconds. Until the next major change.
It has been observed that a WH51 still reported a value of 1.3V and 1.4V after almost 2 years - so they were still good for use.
As a precaution (the batteries should not leak), the are better replaced they being considered empty (⇐1.2V).
After some time Ecowitt started delivering the WH51 together with a plastic cap of the same green colour which is supposed to protect the battery compartment from water ingress.
The WH51 provides a so-called AD value which can be “calibrated” or scaled. While in the agriculatural context of soil moisture AD usually stands for “Allowable Depletion” (see https://soilsensor.com/soil/soil-moisture-and-irrigation/ ), the Ecowitt uses a more simplistic definition and refers to a “Analog to Digital” Soil Moisture Calibration or scaling:
The soil moisture sensor provides for optional two-point linear calibration. This is important due to different soil types and density. The calibration equation is defined as: % Soil Moisture (calibrated) = (Now AD – 0%AD) *100 / (100%AD – 0%AD) Where AD stands for “analog to digital” and is the unscaled digital value, Now AD is the currently measured AD and the other parameters are described below.
0% Soil Moisture Set Point To determine the 0% soil moisture, collect a soil sample in a cup from where the sensor will be installed, and allow the soil to completely dry out. Next, place the soil sensor in the medium and allow the sensor to stabilize for one hour. Next, set the 0%AD calibration set point to the Now AD value.
100% Soil Moisture Set Point To determine the 100% soil moisture, collect a soil sample in a cup from where the sensor will be installed, and add water and mix until the soil is saturated, and there is no standing water. Next, place the soil sensor in the medium and allow the sensor to stabilize for one hour. Next, set the 100%AD calibration set point to the Now AD value.
Customize and Reset Once the 0%AD and 100%AD are entered, set Customize to ON. To return to the non-calibrated settings, set Customize to OFF. Select Reset to restore to factory default
Starting with GW2000 firmware 3.1.5 and WS6210 firmware 1.0.4 all IoT capable consoles/gateways will be able to support 16 instead of before 8 WH51 soil mositure sensors.
all WH51 sensors channel 1-16 will can be used for smart IoT plans (latest firmware upgrade assumed)
reseller product name: Froggit DP100, Ambient WH31SM
———————————————————————————————————————————————————————————-
The WH51L is a soil moisture sensor for more difficult environments. While the normal WH51 is generally well suited for potted plants etc., it showed reception problems with the respective console at low-lying measuring points. With the WH51L, the transmitter sits in a remote housing, which also has a display window, and has a one metre long cable, so that better and more distant reception (100 m free field) is possible by mounting it higher above the ground. It shares the eight WH51 channels with the “normal” WH51, analogue to the WH31 family or WN34 family.
In addition, the measuring probe can of course now also be inserted deeper into the ground, which opens up a wider range of applications depending on the plant, root depth, etc. The WH51 (without L) could be inserted just 10-15 cm deep.
The sensor has also been available to order in the Ecowitt shop since 14 November 2023 (https://shop.ecowitt.com/products/wh51l ).
———————————————————————————————————————————————————————————-
WH51RF
Ambient sell a WH31 with a specially designed housing under the name WH51RF
More information under WH51RF (RF = refrigerator)
———————————————————————————————————————————————————————————-
WH53
an indoor/outdoor temperature (no humidity !) sensor - works with the WH0280 WH0300 WH0310 mini-consoles only - 433 MHz models only. Up to three can be connected - channel choice inside the housing.
———————————————————————————————————————————————————————————-
WH54/WN54 - LDS01
laser-based water level and snowfall height detection sensor
(prospective release date: March 2025)
For the WH54 (a.k.a Laser Distance Sensor LDS01) four channels are available per one console.
The display and transmission housing is of the WN34 type, and between housing and sensor (the level meter) a 1.5 meter long cable is attached. (similar to the WH51L - see metrics picture below)
The sensor utilizes laser measuring technology, providing up to
- 4 meters of measurement range when not exposed to natural light and
- 3.5 meters range when exposed to natural light
the sensor shows three values:
air (distance between sensor and surface [water, snow]),
thi (total height, user defined distance between sensor and ground) and
depth (depth = thi -air)
The sampling rate is once every 20 seconds - data transmission is every 80 seconds
If the measurements between two adjacent readings differ by more than 5%, the data is immediately sent.
The sensor then enters the so-called fast measurement mode where the sampling and the transmission is every 10 seconds.
the units displayed on the sensor display can be chosen by a switch inside the housing under the battery.
units shown in the apps or in the WebUI will depend on the unit settings chosen for your console in the respective app or WebUI. The unit will be the same chosen for rain data.
1 | mounting bracket |
---|---|
2 | laser distance measuring module |
3 | Cable (connecting main display unit and laser distance measurement module) |
4 | Main display and processing unit |
top snow height
(Air)
below water level
(Air - Depth)
an exploded drawing of the sensor
metrics
setup water scenarios
setup snow scenario
the specification speak of a measurement field of view angle of 5° (to be updated !).
however that needs to be updated as Ecowitt has introduced an additional lens to focus the laser beam. The angle is now 2° ⇒ at 1 m distance the cone covers a circular area with a radius of 3.5 cm ⇒ arctan (0.035) = 2°
⇒ diameter at 1 m is 7 cm, at 3.5 m (max distance in daylight) = 24.5 cm and at 4 m (dark) = 28 cm
That also means that these are the minimum distances from a wall or any other obstacle (e.g. pipe diameter)
realising the need for a heater and resulting from that for a stronger power supply than the initially conceptualized 1.5 V AA battery, the sensor was redesigned and a battery package holding 8 AA batteries was added. A dummy battery building the connection to the external battery compartment is used in the (WN34/35,WH51L,LDS01) standard display housing.
On a HP25x0 console the display will not be on the main screen but on the Extra-Sensor page (4 x arrow-up/down button). Depth will only be shown once “total height” is configured.
on the HP25x0 and the WebUI calibration page the heater-on counter can be reset/changed.
———————————————————————————————————————————————————————————-
WH55
A water leak detector. Powered by 2 AAA batteries, this sensor reliably reports any puddles that occur - both acoustically via a loud beeper and with corresponding notifications on the console or the (supporting) weather services. With Ecowitt you can be notified by e-mail.
The transmission interval is 60 seconds.
Froggit: DP70
———————————————————————————————————————————————————————————-
WH57
The lightning sensor reports and counts lightning within a radius of approx. 40km and outputs the approximate distance. An AS3935 chip is used internally.
The built-in sensor receives signals in the 500 kHz band and analyses them for patterns characteristic of lightning discharges.
Of course, this can also lead to “false alarms”, especially if, for example, household appliances also generate such patterns.
Starting refrigerators, for example, often generate so-called false-positive events. It is therefore generally advisable to install the device outside, possibly in a protective housing.
Meanwhile Ecowitt offers the WH57 together with their RS0001 radiation shield which is pretty useless for a T/RH sensor exposed to direct sunlight. But as a protection against debris and rain it can be helpful.
When an event identified as a lightning discharge is registered, an orange LED lights up in the viewing window with the lightning symbol.
The transmission interval is 79 seconds.
When the first lightning bolt is registered (and also for subsequent lightning bolts), the 79 second interval is interrupted and restarted so that the message arrives promptly.
The timestamp of the last lightning event is set by the console that receives the WH57 signal. The distance and number per measurement interval come from the WH57.
The (one) WH57 can only be displayed on the screen on an HP25x0 or HP350x console. The Ecowitt app and the WS View Plus app also display the lightning data (WSV+ also in real time if the local gateway API is available) as does the Ecowitt dashboard - on a one minute basis if that updating option is chosen in the console.
As there are always uncertainties regarding the setting of the DIP switches - here is an extract from the instructions:
The left-hand DIP switch decides whether the antenna is used inside (top) or outside (bottom). The second switch from the left (apparently) switches between two antennas. And the two switches on the right change the sensitivity.
When delivered, all DIP switches should (actually) be down. However, there have already been reports that the DIPs were in a different position on arrival.
More information about how the WH57 works: as3935_datasheet_en_v2.pdf
Many WH57 user deploy the WH57 outside e.g. fixed at a mast inside some protective cover or housing with the default settings - i.e. all DIP switches in the lower position.
Testing/troubleshoot the WH57 function:
create a spark with a traditional lighter or a camera flash close to the sensor - the orange sensor LED should flash and it should register the discharge pattern as a lightning in the console/app (even though this would be a false-positive). If nothing happens, resetting the sensor may help (= take off batteries, wait for a minute, re-insert)
reseller product name:Froggit DP60, GARNI G094L, Ambient WH31L
————————————————————————————————————————————————————————————————-
WFC01
the WFC01 intelligent water timer, valve (WittFlow)
for details see
WFC01
————————————————————————————————————————————————————————————————-
AC1100
the AC1100 intelligent switch (WittSwitch)
for more details see AC1100
————————————————————————————————————————————————————————————————-
HP10 "WittCam" weather camera
Not a sensor but a webcam that takes a photo at a definable interval and sends it to Ecowitt.net, which then generates a film from the individual photos. The technical specifications are somewhat confusing on Ecowitt.com, as they describe characteristics that a user would not normally recognise. The camera is IP66 protected against water and solid bodies and has a resolution of 2 MegaPixels. The lens angle is 150°. Image files are generated in JPG format and transferred to the Ecowitt Cloud, where a time-lapse film can be created from them. Hosting images in the Ecowitt Cloud is free for 7 days. Pricing models for longer storage are not yet published. Size: 41*41*71.5mm
Details:
You can retrieve current images from the local network via http/GET.
Only images are created - no video stream. Formats: 640 x 480 and 1600 x 1200 pixels.
Transmission via FTP is not yet available at the time of delivery (March 2024), but is promised to be added later via an upgrade.
The camera connects to the local router via WiFi (2.4 GHz) and is a device in the local network.
Images are taken every 5/10/15/20/25 minutes, depending on the setting, and transferred to the Ecowitt cloud.
The camera has a WebUI or can be configured via the WS View Plus app.
The HP10 has been a possible device in the WS View Plus app for some time.
The HP10 manual can now be downloaded from Ecowitt (English): https://osswww.ecowitt.net/uploads/20220909/HP10%20manual.pdf
The official operating range is between 0 °C and +50 °C; users from North America report perfect functioning down to -22 °C.
Below an inside view of the HP10 provided by wxforum.net user @nordos
————————————————————————————————————————————————————————————————-
5. how to connect ("pair") your console/gateway to your router
5.1 overview
WiFi provisioning or pairing or connecting your console/gateway to your local WLAN
when you use the LAN (Ethernet) interface of a GW2000 or GW3000, then you just have to plugin the network cable at both ends (console and router). The router should then instantly provide the IP address and the device can be configured with all the tools (apps, WebUI) shown below - the connection via WLAN is a longer process - see below
5.2 procedure(s)
you can only start the pairing process when the console WLAN access point (AP) is active (exception: GW2000, GW3000, ObserverIP 2.0, Ambient Weather Network Hub 2.0 which also have a LAN interface and where the pairing can be done alternatively using by the help of a LAN cable.). The AP will only be active or can only be activated by pressing a button or a button combination [see console manual], when the console is powered by an external DC power supply. When running on batteries only, the AP will remain switched off (exception WS6006, WS6210).
you can only connect the consoles/gateways to a 2.4 GHz WLAN
(if you also run a 5 GHz WLAN with the same SSID, switch it off until the pairing is successfully completed !)
before you start the pairing process, switch off your mobile network in the smartphone or tablet you are using for the pairing
usually this is done by switching on the flight mode (air plane symbol) and then switch on WiFi only
once the pairing is successfully completed, you can switch off the air plane mode which will activate your mobile network connection again
you will be guided by the WS View Plus app through the whole process
below we will describe this process step-by-step and explain what you have to do and why
in principle you tell your console how it can log in and register with you router
1. start WS View Plus
(you will have to download and install it first on your smartphone from your app store [GooglePlay, AppleStore])
you will see the device list - the number of entries is the number of Ecowitt consoles the app detects in the local network
the entries in the device list will look as shown in the above picture (WS View)
(when this is your first time to connect an Ecowitt console with your router, the device list will be empty)
in the WS View Plus app you can select a device as Favourite - the device will then show in the Favourites list. When making a device list entry to a Favourite, you can assign an icon/picture of the console type and can change the default name. Default is EasyWeather-WIFIxxxx, EasyWeatherPro-WIFIxxxx or device-WIFIxxxx (see example above)
2. press on the (+) button at the bottom center
you will get a list of console pictures
3. select your console type
4. activate the WiFi mode of the console
you will receive instructions how to put the console into WiFi mode
(= the console starts an internal WLAN with the name of the device or the WiFi firmware - see above - to which you can connect with your Smartphone or tablet)
5. connect to the WLAN of the console
in the WLAN/WiFi setup of your smarthone the name of the console WLAN network (SSID) will appear in the list of available network. For a HP25x0 console it will be EasyWeather-WIFIxxxx or EasyWeatherPro-WIFIxxxx, where xxxx are the last four characters of the console's MAC address. For a GW1200 it would be GW1200-WIFIxxxx.
You select this wireless network and connect to it. Ignore the message that there is no internet connection available. That's correct, but for what you are going to do you don't need it.
6. provide router login information to the console
Once the connection is successful, you will see a page where you can select the mobile networj of your WLAN router or access point. You can make the smartphone search for this network (SSID) and select it. Then you also have to enter the password of your router. The console stores this and will later establish the connection with the router.
you will choose “Next” from here and the console with try to pair with the router (login with SSID and password and then receive an IP address from the router). Once this is completed, the app will take you back to the network list where you can now choose the network you usually use with your smartphone or tablet.
7. start using your console in your local network and with the weather services you choose
as a result your console will now be able to post data to the internet via your router when you have this posting activated in the console.
if your console has the local Ecowitt gateway API, you can now also see the live data in WS View Plus /or in the WebUI connecting with the IP address of the console. This IP address can either be found in your router or in the device list of WS View Plus.
In rare situations, depending on your network setup, it can happen that your router has run out of its IP address budget of DHCP assigned IP addresses - then the console/gateway won't get an IP address assigned.
you will then have to extend the dynamic IP address budget/range of the router.
Once you have finally received an IP address, set it to “IP Address Mode static” in the WebUI of your device (gateway/console) where possible. With some older device this is not possible (GW1000/WH2650/WS2320/WS2910). The WS View Plus app doesn't offer this option - it's WebUI only
(WebUI is the local webpage of the device showing when you enter the IP address of your console/gateway in the web browser)
if in step 4 you are asked for a network security key,
you (or someone else) has set a password for the WebUI (embedded web page) access earlier and this also becomes the password for the WLAN (“WiFi network”).
For the name (SSID) of the WLAN/access point see step 5 or WiFi firmware.
how to pair your gateway with you local network (LAN) by using a LAN cable ?
(applies to GW2000, GW3000, ObserverIP 2.0, Ambient Weather Network Hub 2.0 gateways)
just connect the gateway via a LAN cable to the local network (router or switch). The router will recognize the device and (if the dynamic assignment of IP addresses [DHCP] is activated, default situation) will pass an IP address to the gateway. The gateway can now be reached in the network by entering http://IP-address-of-gateway into your browser.
how to find out the IP address ?
check the router - usally there is a range of IP addresses, the last one provided in that range, the last number of four triplets e.g. 192.168.1.xxx is likely to be the IP address of the gateway. You will have to very by trial and error.
You can also start the WS View Plus app. It will show Ecowitt devices in the same local network where the console(s) is (are) in with an entry in its device list. Per entry also the MAC address and the IP address are shown.
For a GW2000 the entry in the device list will be:
Device GW2000x-WIFInnnn, MAC nn:nn:nn:nn:nn:nn, IP xxx.xxx.xxx.xxx, VER 3.x.x,
(Ambient Devices will only be shown in WS View Plus up to app version 2.0.48 –> WS View App section)
We recommend to make the gateway IP address static - this you can do in the network configuration of the gateway in its WebUI.
————————————————————————————————————————————————————————————————-
6. firmware - update - versions
before you upgrade your firmware, make sure you have noted down (pencil, photo, screencopy) your calibration and rain total settings - it has often been observed that these data get unintendedly lost during the upgrade. Better safe than sorry !
A procedure how to backup and restore your calibration setting via a script (a sequence of operating system commands) on a Linux based server (e.g. RaspberryPi, NAS server, Linux container etc.) can be found here: - works with all consoles/gateways which have the local http API
NOTE: during a console/gateway restart/reboot (which also happens after a firmware upgrade) the values for maximum daily wind speed (gust) and of a rain event will get lost an strt counting again
there are two types of firmware for the FineOffset/Ecowitt (clone) consoles:
a) WiFi firmware for the upload to the Weather Networks and a customer server (if the console supports), usually starting with EasyWeatherVa.b.c/EasyWeatherPro Va.b.c (or AMBWeatherVa.b.c for Ambient devices)
The separate WiFi firmware is called EasyWeather V.x.y.z (e.g. EasyWeather V.1.6.4) or EasyWeatherPro V.5.x.y for the consoles with a new WiFi modem.
For Ambient consoles the separate WiFi firmware is called AMBWeather V.x.y.z (e.g. AMBWeather V.4.3.5) or AMBWeatherPro V.z.x.y for the consoles with a new WiFi modem.
The consoles with the EasyWeatherPro or AMBWeatherPro WiFi firmware also have a WebUI, which can be accessed in the local network via https://IP-address-of-the-console. They also can, when activated, build their own WLAN (“Access Point” - SSID = EasyWeatherPro-WIFIxxxx or AMBWeatherPro-xxxxxx or WS1965-WIFIxxxx) and when your computer or Smartphone is connected to that network, the console can be reached via IP address 192.168.1.4).Via this network the initial setup/pairing with the local network router can be done via the WebUI. Otherwise WS View Plus or the awnet app is needed. During normal operation it is recommended to switch it off (option on the device settings page in the WeBUI)
if the other features of the WebUI, as the pictures in the quick setup page of the Ambient manual for the WS-2902D suggest, like viewing live data and configuring device settings beyond a WS-1965 or Oberserver IP 2.0 module is questionable and needs to be verified. It's likely to be an error introduced by a copy-and-paste error. It's likely only to be the network and weather network configuration.
b) console/device firmware, which usually just shows the version like Va.b.c (a, b, c = major version, minor version, patch level) which handles the reception and processing and display of the sensor readings
(The reason for the two firmwares lies in the internal construction. With the classical display consoles the main processor handles all activities including a WiFi modem which the WiFi firmware is for)
the GW1200/GW1100/GW1000/WH2650/GW2000, WN19x0 and WS3800/WS39x0 consoles have a combined WiFi/console firmware
(They have a separate WiFi SoC (system on a chip) with its own processor which handles the WiFi communication. They are faster than the classical display consoles: WS2320, WS2910, HP25x0, HP350x)
The above said also applies to the Ambient WS-1965 console (a Ecowitt WN1920 clone) and the Ambient Weather Hub/ObserverIP 2.0 module (an Ecowitt WH2682 gateway with similar functionalities like a GW2000 except for IoT features).
The WH2910 and WH2320/WS2320 also have two different firmware types, but their device firmware CANNOT be updated - it is set by the manufacturer. However, the WIFI firmware can be updated via the app. Certain eatures of the device firmware of the WS2910 depend on the firmware version (see console description)
the upgrade procedure:
there are two to three upgrade procedures depending on the type of firmware (WiFi, device)
WiFi
a. via the WS View Plus app
b. OTA (over the air - here = WiFi) for consoles with the EasyWeatherPro/AMBWeatherPro firmware from inside the console
c. via a WebUI (URL = https://ip-address-of-the-console) for consoles with the new WiFi modem (also EasyWeatherPro WiFi firmware)
the WiFi firmware upgrade page for Ambient consoles with the new WiFi modem and the AMBWeatherPro WiFi firmware looks like this
(Ecowitt (clone) consoles see farther down):
console/device:
the device firmware of the WS2320 and WS2910 consoles cannot be user upgraded
(the below procedure also applies to the Ambient WS-2000, WS-4000, WS-5000 consoles - they share the same firmware)
the device firmware of the HP25x0 and HP350x consoles can be user upgraded
the upgrade is done by the help of a microSD card
(type SDHC only, SDXC doesn't work; format FAT32; max size (defined by SDHC) 32 GB)
it appears that newer HP25x0 consoles (to be recognized by having the EasyWeatherPro WiFi firmware) also have a new SD card reader which can manage SDXC cards. But using large capacity SD cards for storing the sensor values doesn't make much sense - a 16 GB microSD card can hold the maximal possible sensor number data for about 150 years - about 100 backups of 16 MB included.
the file user.bin is downloaded from ecowitt.net (link under “Manuals and Software” at the console page on ecowitt.com or from the WiKi at the “latest firmware” section) as a zip archive and after unpacking/unzipping the file user.bin in copied into the root directory of the microSD card. Then the card is inserted into the console (looking at the display, the contacts of the microSD card should show towards you and the printed surface away from you). Be careful to insert the microSD properly until it snugs in. Once inserted the console applies the firmware upgrade automatically and reboots the console. After the successful upgrade the console deletes the file user.bin from the microSD.
the use of cheap (and therefore often “crappy”) microSD cards can also make the firmware upgrade fail
from device firmware V. 1.9.5 on the device firmware upgrade can be done via the console over-the-air (OTA: here WiFi) for the newer HP25x0 models which have the new WiFi modem and the (recent !) EasyWeatherPro firmware.
below the result of an OTA device firmware upgrade for an Ambient WS-2000/WS-5000 consoles with the new WiFi modem
combined WiFi/device firmware
the upgrade is done via the WS View Plus app (all consoles/gateways with local Gateway API) or the WebUI (WN1980, WS3800, WS39x0, GW1100, GW1200, GW2000). When connecting to the console from WS View Plus by tapping on the entry in the device list, a window with an upgrade-available message appears when a new upgrade has been released. Accepting the upgrade offer will download the new firmware, install it and reboot the device.
in the WebUI an available upgrade is indicated by a red dot at the “Device Settings” option on the left-hand side menu.
below shown is the update via WSView (Plus) app
the WS View (Plus) device list and the upgrade offer after tapping on a device list entry
even though the pictures are from the old (discontinued) WS View app, the procedure is the same in the new WS View Plus app. For this only the background colour has changed from greenish-greyish to white.
the Device List and Favourites List in the new WS View Plus app
(for more details to the WS View Plus app see separate chapter)
the procedure is highly automated.
1. start WS View Plus -
you will see the device list - the number of entries is the number of Ecowitt consoles the app detects in the local network
the entries in the device list will look as shown in the above picture (WS View or WS View Plus)
in the WS View Plus app you can select a device as Favourite - the device will then show in the Favourites list. When making a device list entry to a Favourite, you can assign an icon/picture of the console type and can change the default name. Default is EasyWeather-WIFIxxxx, EasyWeatherPro-WIFIxxxx or device-WIFIxxxx (see example above)
2. select an entry in the device list
there are two scenarios:
1. you own a WS2320, WS2910, HP350x or HP25x0 console (or clone model)
if a WiFi firmware upgrade is available, a pop-up window will appear and offer the upgrade. If you accept, the upgrade will take place and the console will be rebooted. If you reject, the upgrade will only be offered again when you start WS View Plus again from the start. (The app has to be closed and completely removed from the memory - otherwise it will not check for upgrades again).
2. you own a console with the local Ecowitt gateway API which have a combined WiFi/device firmware
if a firmware upgrade is available, a pop-up window will appear and offer the upgrade together with change log information. If you accept, you will be taken to the device settings (caption “System”) and you have to press the “Check new version” button. If a new version is available, a pop-up windows will appear offering the upgrade. If you press “OK”, the upgrade will take place and the console will be rebooted. If you reject, the upgrade will only be offered again when you start WS View Plus again from the start. (The app has to be closed and completely removed from the memory - otherwise it will not check for upgrades again). Alternatively you can go to device settings (Live Data –> More –> Device Settings) and press the “Check new version” button again.
the analogous procedure can be done with the consoles which have an integrated webpage (WebUI). There a red dot will appear next to the “Device Settings” menu item when a new firmware version is available.
you can also choose an automatic upgrade in either the WS View Plus app or the WebUI.
we strongly discourage to use this setting as it is nearly impossible to go back to an earlier firmware version.
Exception: the device firmware of the HP350x and HP25x0 consoles. Here you can use an earlier version of the user.bin firmware file (provided you have kept it).Italic Text
you better wait and check in the weather forums - e.g. https://www.wxforum.net/index.php?board=111.0 what early adopters are reporting.
most of the above said combined in a few-pager can be found here: firmware upgrade procedures
(these procedures ONLY work when you are connected with your update-performing device to the same local network your console is registered to !!! - And to perform an OTA (over-the-air) upgrade, you also need an internet connection to download the firmware from the upgrade-server !)
—————————————————————————————————————————————————————————————————-
console firmware (device, WiFi - latest versions)
(last updated: 10-Jan-2025) - link to firmware changelogs
actual versions are:
WiFi firmware | release | date | models | remarks |
---|---|---|---|---|
EasyWeather | 1.6.9 | 24-May-2024 | WH2320, WH2910, HP2550, HP3500 | (old WiFi modem) |
EasyWeatherPro | 5.1.8 | 08-Jan-2025 | WH2320, WH2910, HP2550, HP2560, HP3501 | (new WiFi modem) |
AMBWeather | 4.3.5 | 13-Mar-2024 | WS-2000, WS-5000, WS-2902 | Ambient consoles |
AMBWeatherPro | 5.1.8 | 08-Jan-2025 | WS-2000, WS-5000, WS-2902D | Ambient consoles, new WiFi modem |
model | current release | release date | remarks | download |
---|---|---|---|---|
HP2550: | 1.9.5 | 15-Mar-2024 | works with all clone models including Ambient | user_v1.9.5_0315.zip |
1.9.6 | 02-May-2024 | device firmware upgrade w/ EasyWeatherPro OTA | user-v1.9.6.zip | |
1.9.7 | 11-Jul-2024 | device firmware upgrade w/ EasyWeatherPro OTA works with all clone models including Ambient | user_v1.9.7.zip | |
1.9.8 | 13-Aug-2024 | device firmware upgrade w/ EasyWeatherPro OTA works with all clone models including Ambient | user_v1.9.8.zip | |
1.9.9 | 28-Nov-2024 | device firmware upgrade w/ EasyWeatherPro OTA works with all clone models including Ambient | user_v1.9.9.zip | |
2.0.0 | 08-Jan-2025 | device firmware upgrade w/ EasyWeatherPro OTA on Ambient WS-2000/4000/5000 with old WiFi modem (HW 1.0) SLP upgrade via SD card only | hp2550_v2.0.0.zip | |
2.0.1 | 17-Jan-2025 | device firmware upgrade w/ EasyWeatherPro OTA on Ambient WS-2000/4000/5000 with old WiFi modem (HW 1.0) SLP upgrade via SD card only | hp25x0-user_v2.0.1.zip | |
HP2560: | 1.9.6 | 02-May-2024 | device firmware upgrade w/ EasyWeatherPro OTA | user-v1.9.6.zip |
1.9.7 | 11-Jul-2024 | device firmware upgrade w/ EasyWeatherPro OTA | user_v1.9.7.zip | |
1.9.8 | 13-Aug-2024 | device firmware upgrade w/ EasyWeatherPro OTA | user_v1.9.8.zip | |
1.9.9 | 28-Nov-2024 | device firmware upgrade w/ EasyWeatherPro OTA | user_v1.9.9.zip | |
2.0.0 | 08-Jan-2025 | device firmware upgrade w/ EasyWeatherPro OTA | hp2550_v2.0.0.zip | |
2.0.1 | 17-Jan-2025 | device firmware upgrade w/ EasyWeatherPro OTA | hp25x0-user_v2.0.1.zip | |
HP3501: | 1.7.2 | 29-Dec-2023 | hp3500_v1.7.2-1229.zip | |
: | 1.7.5 | 10-May-2024 | hp3500_v1.7.5.zip unpack files and rename to picture.bin and Firmware.bin and copy to SD card |
|
: | 1.7.7 | 11-Oct-2024 | hp3500_firmware_v1.7.7.zip unpack files and rename to picture.bin and Firmware.bin and copy to SD card |
Combined firmware
displayless consoles :
model | current release | release date | remarks |
---|---|---|---|
GW1000: | 1.7.7 | 12-Oct-2023 | WS View Plus >= 2.0.32 needed |
WH2650: | 1.7.7 | 12-Oct-2023 | |
GW1100: | 2.3.7 | 22-Jan-2025 | |
GW1200: | 1.3.4 | 20-Jan-2025 | |
GW2000: | 3.2.1 | 21-Jan-2025 | WS View Plus >= 2.0.50 needed |
GW3000: | 1.0.2 | 10-Jan-2025 | |
WS6006: | 1.1.37 | 12-Nov-2024 | PC software 1.7.1 |
WS6210: | 1.0.7 | 17-Jan-2024 | |
WH2682: | 2.2.6 | 04-Jul-2024 | Ambient OBSERVERIP2 |
consoles with display :
model | current release | release date | remarks |
---|---|---|---|
WN1900: | 1.2.4 | 15-Jan-2024 | |
WN1910: | 1.2.4 | 15-Jan-2024 | |
WN1920: | 1.3.5 | 17-Jan-2025 | |
WN1980: | 1.3.5 | 17-Jan-2025 | |
WN182x: | 1.3.5 | 17-Jan-2025 | |
WS3800: | 1.3.4 | 20-Jan-2025 | |
WS39x0: | 1.3.4 | 20-Jan-2025 | |
WS-1965: | t.b.d. | xx-xx-202x | Ambient WS-1965 ~ Ecowitt WN1920 |
name | latest version | |
---|---|---|
WS View Plus | 2.0.53 | 03-Jan-2025 |
Ecowitt | 1.1.51 | 06-Jan-2025 |
outdoor arrays
name | latest version | ||
---|---|---|---|
WS80 | 1.2.9 | 23-Sep-2024 | downloads 80 firmware |
WS90 | 1.4.9 | 30-Dec-2024 | downloads 90 firmware |
WS85 | 1.0.9 | 27-Sep-2024 | downloads 85 firmware |
———————————————————————————————————————————————————————————————–
sensor firmware (WS80/WS90/WS85)
usually sensors have their firmware for their lifetime, but with the sensor array, different hardware revisions and related firmware revision are possible.
if a (re-calibration of the ultrasonic anemometer (wind) readings is needed, i.e. when a zero baseline needs to be (re-)established, this is done via the CAL button of the WS80/WS85/WS90 arrays with the anenometer portion put into windless conditions. example see picture.
Putting the array into a cardboard box with open top or taking it inside the building will also do.
after holding the CAL button for 3 seconds, the light (blue LED) will be bright for 5 seconds and then start to flash. After some time the light will go off and the wind speed will be reset to zero.
You will need a USB data (!!) cable with a male micro-USB type A (or micro A) end piece to plug into the female USB outlet of the WS80/WS85/WS90 array. Not every USB cable you use for charging is a data cable. Charging cables often use only two wires for the electricity while data cables have to more wires connected (4 wires together) for the data exchange.
Tool to install a sensor firmware upgrade with a Linux or MacOS computer: WS80/WS90 firmware upgrade Linux/MacOS
Tool to install a sensor firmware upgrade with a Windows computer:
WS80/WS90 firmware upgrade Windows
for the WS85 upgrade software (so far only under Windows) see WS85 section below
if you have trouble getting your upgrade done, have a look at the troubleshooting section
————————————————————————————————————————————————————————————————-
WS80
firmware
V. 1.2.4 (17-Jan-2023) - Optimize low/no wind speed detection algorithm V .1.2.5 (05-Apr-2023) - reduce/fix the problem of wind speed and direction remaining unchanged after rain V. 1.2.8 (15-Apr-2024) - Optimize wind speed measurement. -- in detail * Recognize the polarity of the ultrasonic probe; * Power-on adjustment of 4 drive square waves, solving the issue of the first RF data wind speed not resetting to zero. - this update is mainly meant to improve readings at low wind speed V. 1.2.9 (23-Sep-2024) - Optimize the ultrasonic sensor for wind speed measurement - Optimize the wind speed algorithm to enhance accuracy - Add feature to switch the (blue) RF LED light ON or OFF by pressing the CAL button three times
version | firmware | release |
---|---|---|
1.2.8 | WS80 Firmware V1.2.8 Upgrade.zip | 15-Apr-2024 |
1.2.9 | WS80 Firmware V1.2.9 Upgrade.zip | 23-Sep-2024 |
To ensure accuracy with the upgrade, a recalibration to zero is required for it to take effect. –> press and hold CAL button in an air movement free environment e.g. a bigger cardboard box for > 10 seconds
Tool to install a sensor firmware upgrade with a Linux or MacOS computer: WS80/WS90 firmware upgrade Linux/MacOS
Tool to install a sensor firmware upgrade with a Windows computer:
WS80/WS90 firmware upgrade Windows
————————————————————————————————————————————————————————————————-
WS90
ATTENTION -
the Ambient WS90 light-weight version (WS-4000-ARRAY) CANNOT be upgraded with the sensor firmware of the standard Ecowitt WS90 array - Froggit DP1100 array can !!!
(different chip set !)
firmware upgrade changelogs (downloads see below)
V. 1.1.7 (April 2022) - improve rain detection pattern - improve rain measurement accuracy. V. 1.1.9 (May 2022) - improvement of wind readings V. 1.2.3 (14-Jul-2022) - Increased sensitivity for mist and drizzle rain detection. - sensitivity for high rain rate adjusted to provide better lineararity. V. 1.2.5 (13-Aug-2022) - 32K XTAL working state check after power on. If no possible for external timing crystal working, switch to internal timing clock, enhancing item robust during different conditions. - Increase mist or drizzle rain sensitvity. - We recomend most user to set Rain1 gain setting to 0.75 with GW1x00/GW2000 hub or HP25x0 console series. - Tuning for stormy rain sensitivity alignment. V. 1.2.6 (21-Sep-2022) - useful for V.1.2.5 users where the sensor reacted too sensitive to mist or dew V. 1.3.0 (18-Jan-2023) - Optimize low/no wind speed detection algorithm V. 1.3.2 (29-Mar-2023) - Optimized for rain condition wind measurement algorithm - overcome issue that sensor stop reading wind when water comes to the transducer surface - Optimized for MODBUS version so that active measurement command is included for faster reading speed. -- The fastest measurement can be up to 8 sampling per second - Battery voltage measurement is possible when heater 12v power is applied for hardware version after v2.0. --The early version prior to hardware v2.0 will not be possible to measure battery voltage when 12v external heater power applied V. 1.3.3 (17-Apr-2023) - Optimize rain detection algorithm V. 1.3.8 (25-Oct-2023) - Optimize wind speed measurement -- in detail * Modbus version of piezoelectric full-speed signal collection improvement; * Recognize the polarity of the ultrasonic probe; * Power-on adjustment of 4 drive square waves, solving the issue of the first RF data wind speed not resetting to zero. - Optimize rainfall measurement - Press the CAL button three times in quick succession to toggle the LED on/off V. 1.4.3 (15-Apr-2024) - Optimize wind speed measurement. -- To ensure accuracy with the upgrade, a recalibration to zero is required for it to take effect. ---> press and hold CAL button in an air movement free environment e.g. a bigger cardboard box for > 10 seconds -- this update is mainly meant to improve readings at low wind speed V. 1.4.6 (23-Sep-2024) V. 1.4.7 (26-Sep-2024) Changelog (same as 1.4.6): - Optimize the ultrasonic sensor for wind speed measurement - Optimize the wind speed algorithm to enhance accuracy - Optimize rainfall measurement V. 1.4.8 (28-Nov-2024) - Supports the new T&H module hardware with dual T&H compensation V. 1.4.9 (30-Dec-2024) - Optimize the temperature and humidity compensation algorithm. - Optimize the light sensor algorithm. - Optimize the light rain detection algorithm to reduce false readings caused by fog.
version | firmware | release |
---|---|---|
1.2.3 | WS90 Firmware V1.2.3 Upgrade.zip | 14-Jul-2022 |
1.2.5 | WS90 Firmware V1.2.5 Upgrade.zip | 13-Aug-2022 |
1.2.6 | WS90 Firmware V1.2.6 Upgrade.zip | 21-Sep-2022 |
1.3.0 | WS90 Firmware V1.3.0 Upgrade.zip | 18-Jan-2023 |
1.3.2 | WS90 Firmware V1.3.0 Upgrade.zip | 29-Mar-2023 |
1.3.3 | WS90 Firmware V1.3.3 Upgrade.zip | 17-Apr-2023 |
1.3.8 | WS90 Firmware V1.3.8 Upgrade.zip | 25-Oct-2023 |
1.4.3 | WS90 Firmware V1.4.3 Upgrade.zip | 15-Apr-2024 |
1.4.6 | WS90 Firmware V1.4.6 Upgrade.zip | 23-Sep-2024 |
1.4.7 | WS90 Firmware V1.4.7 Upgrade.zip | 26-Sep-2024 |
1.4.8 | WS90 Firmware V1.4.8 Upgrade.zip | 28-Nov-2024 |
1.4.9 | WS90 Firmware V1.4.9 Upgrade.zip | 30-Dec-2024 |
Tool to install a sensor firmware upgrade with a Linux or MacOS computer: WS80/WS90 firmware upgrade Linux/MacOS
Tool to install a sensor firmware upgrade with a Windows computer:
WS80/WS90 firmware upgrade Windows
————————————————————————————————————————————————————————————————-
WS85
The WS85 has it's own upgrade procedure. The hardware (cabling) used is the same, the software used is different.
A new Tool “EcowittSPTool” will perform the upgrade. So far only a Windows version is available; a MacOS version is under development.
to perform the upgrade, follow the upgrade instructions in the guidelines: WS85 Firmware Upgrade Guidance
firmware upgrade changelogs
V. 1.0.7 product release version V. 1.0.8 (01-Jul-2024) - improved readings at low wind speeds V. 1.0.9 (01-Oct-2024) - Optimize the ultrasonic sensor for wind speed measurement - Optimize the wind speed algorithm to enhance accuracy - Optimize rainfall measurement
version | upgrade tool | firmware | remarks |
---|---|---|---|
1.0.7 | n/a | n/a | sales release version |
1.0.8 | ecowittisptool_v1.0.0.zip | ws85_v1.0.8_app.zip | see upgrade guidance |
1.0.9 | ecowittisptool_v1.0.0.zip | ws85_v1.0.9.zip | see upgrade guidance |
————————————————————————————————————————————————————————————————-
what is my actual firmware version ?
owners of a GW1100, GW1200, GW2000, WN1980/WN182x, and WS3800/WS39x0 console can verify their WS90 firmware version by hovering the mouse over the WS90 icon in the SensorsID section of the WebUI
From version 2.0.36 on the WS90 firmware version is also shown in the WS View Plus app, section Sensors ID in the very right of the sensor line.
Users of a HP25x0 (and any other) console with a WS90 can view their firmware version in the Ecowitt dashboard hovering the mouse pointer over the “Reporting …” line on top; (works also with/in the Ecowitt app)
alternatively one can have the console post (temporarily) to http://ear.phantasoft.de* and find their version there. First connect via browser and follow the instruction.
*) see also Custom Server - end of section
So far WS80/WS90 firmware upgrades could only be performed with a Windows computer.
Now (02-Jun-2023) there is also an instruction available how to perform the WS80/WS90 firmware upgrade from a Linux (derivate) or MacOS based server/computer: https://osswww.ecowitt.net/uploads/20230602/Flashing%20firmware%20for%20WS90_80%20on%20MAC%20or%20Linux%20system.pdf
the firmware version of a WS80 cannot be shown
————————————————————————————————————————————————————————————————-
console firmware changelogs
NOTE:
you may have to scroll to the right to read the full text of some of the entries below
change log for GW3000 firmware 1.0.0 thru 1.0.2
V. 1.0.2 (10-Jan-2025) - supports 16 soil moisture sensors to be stored on the SD card. - Invalid values are uniformly marked with '--' in SD card data. - Support customized MQTT server. V. 1.0.1 (29-Dec-2024) -Fixed some RF sensors not receiving issues (e.g. only one WH41/43 was registered even though two were present). -Supports WU and WeatherCloud upload time interval settings. -Supports LDS01 laser distance sensors. V. 1.0.0 (05-Dec-2024) release version
change log for WS6210 firmware 1.0.4 thru 1.0.7
V. 1.0.7 (17-Jan-2025) - Supports LDS01 laser distance sensors. - IoT Smart supports new triggers and actions. - Adds low-power Wi-Fi upload method. V. 1.0.6 (04-Dec-2024) - Compatible with the 4G module of EG916-GL. - Fixed some unreliable sensors reception . - Optimized the handling process for failures occurring via 4G uploads. - Changed the custom server upload interval unit to minutes V. 1.0.5 (11-Oct-2024) - Fixed issue with rainfall data not resetting. - Optimized battery over-discharge issues. - Optimized the raining algorithm V. 1.0.4 (public device release date) - Displays rain status. - IOT Smart supports rain status, soil moisture sensor CH1~16 and AD values. - WebUI supports setting upload intervals for WU and WeatherCloud servers.
change log for WS3800/WS39x0 firmware 1.2.6 thru 1.3.4
1.3.4 (20-Jan-2025) - Supports LDS01 laser distance sensors - IoT Smart supports new triggers and actions (e.g. sunrise, sunset and offset) - optimized screen date display 1.3.3 (18-Nov-2024) - The HTTP Local API (get_livedata_info) now includes debug information (heap, runtime, interval [custom server]) - Optimized Wi-Fi station driver - Fixed memory leak issues 1.3.2 (08-Nov-2024) - supports 16-channel soil moisture sensors - supports WS85 and WS90 rain state detection - supports local web pages to control IoT sub-devices - fixed screen flickering issues and other known bugs 1.3.1 (04-Nov-2024) - supports 16-channel soil moisture sensors - supports WS85 and WS90 rain state detection - supports local web pages to control IoT sub-devices 1.3.0 (30-Apr-2024) - fixed bug with WH41 and WH46 introduced with 1.2.9 1.2.9: (25-Apr-2024) - Added support for WS85 wind and rain sensor. - Added support for automatic backlighting of web page control. - On battery power only, in order to reduce power consumption, no longer turns on wifi function. 1.2.8.1: (25-Mar-2024) - Reduce high-pitch sound noticeable in quiet night time. 1.2.8 - Implemented date and week number display rotation on LCD. - Optimized the login page for the website. - Fixed some known bug. 1.2.6 market release version
Change log for GW1200 firmware 1.2.2 thru 1.3.4
V. 1.3.4 (20-Jan-2025) - Supports LDS01 laser distance sensors - IoT Smart supports new triggers and actions (e.g. sunrise, sunset and offset) - Optimized router reconnection after disconnection V. 1.3.3 (19-Nov-2024) - Supports 16-channel soil sensors and WS85/WS90 rain state detection - Supports local web pages to control IoT sub-devices - The HTTP Local API (get_livedata_info) now includes debug information (heap, runtime, interval [custom server]) - Optimized Wi-Fi station driver 1.3.2 - Optimize RF reception performance - The TCP/IP protocol supports obtaining heap size. 1.3.1 - Fixed for WH46 transmitter not receiving 1.3.0 - Added support for WS85. - Fixed some known bug. 1.2.8: - supports IOT device WFC01 and AC1100 - external T&HP sensor can replace indoor temperature, humidity, pressure data 1.2.2: - supports IOT device WFC01. - supports smart scene function.
Change log for GW1000/WH2650 firmware 1.6.9/1.7.0/1.7.1/1.7.2/1.7.3/1.7.4/1.7.5/1.7.6/1.7.7
1.7.7: - support WN34D - support WH46 (WH45 w/ new firmware for PM1, PM4) - fix known bugs 1.7.6: - Fix the bug that the yearly rainfall does not clear to zero - Support multi-channel sensor data uploading to Wunderground 1.7.5: - Weekly, monthly and yearly rainfall reset 0 at the same time as daily rainfall reset 0. - missing "r" in totalrainin ("totalainin") for custom server posts, introduced with 1.7.4, corrected again 1.7.4: - fix the bug that does not turn off the AP after connecting to the router - support WN34 calibration - support the compensation of solar radiation effects on outdoor temperature readings (you need WS View Plus >= V. 2.0.32 !!) - repair the total rainfall supported during customized uploading earlier: 1. Support WS90 related data reception, calibration and upload. 2. Fix the bug of abnormal startup of the system. (1.7.2) 3. Fix WU upload bug (1.7.0, 1.7.1) 4. Fix event rain display bug (1.7.3). Please use the latest version of WSView Plus app to check the data after upgrading the firmware WSView+ >= V2.0.30 needed - in 1.6.9 no upload to WU took place, fixed in 1.7.0; in 1.7.0 wind data wouldn't upload to WU, fixed in 1.7.1; abnormal reboots, fixed in 1.7.2
Change log for HP350x device firmware 1.7.2 thru 1.7.7
------------------------- V 1.7.7 ------------------------- Fix the bug that some batches of devices occasionally crash ------------------------- V 1.7.5 ------------------------- - Support for multi-channel temperature and humidity interface residents - Support WH46 sensor - Support WN34D sensor, temperature range (-55° to 125 °) - Support for WS85 sensor - Support for SD card status display - Fixed some known bugs ------------------------- V 1.7.2 ------------------------- - Supported WS90 haptic array. - Added option and page piezoelectric rain gauge. - Added option reset rain data - Added calibration option temperature, wind and light - Moved the page sensor ID into page about ------------------------- V 1.7.0 ------------------------- - WN34,35 sensor supported. - correct one bug for WU service upload. ------------------------- V 1.6.9 ------------------------- - Correct spelling mistake - Correct bug for wrong max temperature range. - Fix the problem of incorrect configuration parameters ------------------------- V 1.6.7 ------------------------- - Add scrolling display for WH45 CO2 Sensor data in the main interface - Add independent data/ID/Calibration display interface for WH45 CO2 Sensor
Change log for HP25x0 device firmware
V. 2.0.1 (17-Jan-2025) - Supports LDS01 heat count statistics. - Fixed a bug that choosing certain display languages would cause a crash. V. 2.0.0 (31-Dec-2024) - introduce automatic sea level pressure calculation - support LDS-01 laser distance sensors V. 1.9.9 (28-Nov-2024) - Modify the 10-minute average wind speed calculation. - Part of the AQI sensors added to display the DC icon when it works. - Fix bugs about the OTA process, display icon, rain display logic, and SD card storage. ------------------------- V. 1.9.8 (13-Aug-2024) ------------------------- - Fix the bug where the voltage of the WS90 supercapacitor is not being uploaded to the Ecowitt server. (While the wifi firmware is EasyWeatherPro_V5.1.5) ------------------------- V. 1.9.7 (11-Jul-2024) ------------------------- - Optimize some display and different language translation issues - Fix the incorrect record time in the history data interface - Optimize parameter storage ------------------------- V 1.9.6 (02-May-2024) ------------------------- - add support for WS85 3-in-1 Rain & Wind sensor ------------------------- V 1.9.5 ------------------------- * Add eight channel AD values for WH51 soil moisture sensor data upload via WiFi * Update the calculation parameter for outdoor temperature compensation, changing from the average of the last eight gusts to the average wind speed over 10 minutes * Modify the color of the 10-minute average wind direction indicator on the main interface with a black background, changing it from dark gray to white * If the rainfall display is set to piezoelectric rain gauge, display 'piezo' below the daily rainreading * When (with a HP2560 console) a temperature, humidity, and barometric pressure sensor is detected, set the T&HPsensor to 'Disable' by default. When the user enables the T&HP sensor, give its data higher priority over the built-in probe * Change domain names (on the Weather Services page): www.Wunderground.com to Wunderground.com www.Weathercloud.net to Weathercloud.net www.WeatherObservationsWebsite.com to wow.metoffice.gov.uk www.ecowitt.net to ecowitt.net * Add support for the WN35 transmitter in the Czech language version * When receiving a signal from the WH46, add PM1.0 and PM4.0 to the cycle on the maininterface * Add a switch to switch off WiFi completely (Settings --> WiFi scan) * Implement host firmware OTA updates; if auto OTA is checked, perform an automatic OTA upon first power-up and then daily thereafter ("host firmware" = device firmware - with recent WiFi firmware EasyWeatherPro only) * Add a 10-minute gust display feature on the main interface, with an option in the 'more settings' to switch between displaying the 10-minute average wind speed or the 10-minute gust * Change the maximum Air Quality Index (AQI) value to 500 * Add a master switch for alarm sounds on the alarm interface * Set the default time to January 1, 2024 ------------------------- V 1.9.3 ------------------------- - Resolve the problem of potential parameter loss when configuring settings - The longitude is set to 0 degrees by default. In newer versions, it is displayed as East longitude, whereas in older versions, it is displayed as West longitude. ------------------------- V 1.9.1 ------------------------- - Add support for Russian language. - Add an OK shortcut button when entering a Wi-Fi password on the keyboard - Add automatic time zone detection feature, which is enabled by default. It will automatically retrieve the time zone and time when connected to the internet, and the time calibration will occur 5 seconds after successful time zone detection - Add an option to switch between apparent temperature and perceived temperature in the "more" interface, and the corresponding display on the main interface should also switch accordingly - Adjust the minimum upload interval for custom servers from 16 seconds to 8 seconds - Add an AFC (Automatic Frequency Control) switch function in the setup interface, whichis set to OFF by default. Customers can try turning on this feature when encountering unstable RF reception - Support for WN34D temperature sensor with a specific temperature range - Fix the issue where the humidity names are all in German in the ID setup interface - Fix the issue where the indoor multi-channel temperature and humidity data from the WH45sensor are not refreshing on the main interface - Change the wind speed unit from "btf" to "bft" - Modify the Dutch language ------------------------- V 1.9.0 ------------------------- - WiFi password changed to show “*” during the input stage - Bug fix for multichannel PM2.5 display on the main UI - Restore multichannel sensor data quick brief display - Correct spelling mistake on About page - When on board barometer sensor failed, WH32 indoor sensor will be adopted as indoor data source - Spelling and grammar improvement for Dutch, French, Spanish and Portuguese language - Expand the calculated “feels like” temperature range. Originally is limited to the arrange of -40℃ to +60℃ -------------------------- V 1.8.7 -------------------------- The WH30 default channel name is changed in Czech "G092H CHx" to "G092H KAx" "T&H CHx" or "CHx" to "G092H KAx" --------------------------- V 1.8.6 --------------------------- 1. Optimized code about SD card storage 2. German translation text modified 3. Czech translation text modified 4. Portuguese translation text modified -------------------------- V 1.8.5 -------------------------- During the internal (Ecowitt) testing, 1.8.2, 1.8.3, 1.8.4 was released, but finially we have all these 4 versions combined to be 1.8.5. 1. With WiFi modem firmware version after Pro5.0.8, the WU account setting for ambientweather has disabled. New account setup has be implemented. This dosesn't affect ecowitt customer. 2. Fix some spelling mistake for Portuguese Language for pressure, dewpoint, wind direction etc. 3. Data validation check for WS90 sensor added. This is to prevent console picking up data wrong. 4. Dual RTC clock introduced. If 32k external XTAL is not working, then internal RC 32k timer clock will be switched over. This is to enhance system stability. 5. NIST time update plane changed from once per day to once per two hours. 6. Timing check for data set in added in preventing from generating two data set in its data record. 7. Update a flash data entity for PiezoRain 8. Rain reset for week, month, year follow daily rain reset time at user's choice. 9. If a RTC crystal failed, a message of "The external 32768 crystal is abnormal!!!" message will be displayed. ---------------------------- V 1.8.1 ---------------------------- 1. OTA feature supported for WiFi modem. The feature can be edited on "about" page. OTA will be triggered when entering this page, and this feature needs WiFi modem firmware verison to be v5.0.7 or later. Prior to this version, this feature is not supported. 2. Portugese language is supported. 3. Change Deutsch (German) text for SD card back up file: Dewpoint -》 Taupunkt; HeatIndex -》 Hitzeindex; FeelsLike -》 Gefühlte Temperatur; Abs. Leckage -》 Abs. Luftdruck; Rel. Leckage -》 Rel. Luftdruck 4. UPdate French translation to be plural when more than one unit countered. like mins, heures, jours 5.WS90 Rain calibration supported. 6. Outdoor sensor type description for WH65/69 added. 7. WN34 calibration feature added. 8. Default system start up time updated to 20220101. 9. Update feelslike calculation for correct temperature/humidity data source when ws90 sensor is at present. 10. Change "Radiation compeansation" to "Temperature Compensaiton" wording. 11. Fix a bug for weather forecast. 12. Special character supported on mini keyboard. 13. Other system stability improvements. ----------------------------- V 1.8.0 ----------------------------- Fixed the bug from V1.7.9 that characters will be displayed when pressing key6 when WH51, Wn34, WN35 are not received ---------------------------- V 1.7.9 --------------------------- 1.Added Rainfall data priority option trad./Piezo./No rain gauge means. Now you can set one of them to calibrate rainfall parameters. 2.Optimized SD card write methods that writing 5 items in once when storage interval less than 5 minutes. 3.Fixed the bug that upload rainfall data when relink console. 4.Adjusted icon: Wi-Fi, lightning, rainfall. 5.Changed translation for German, Spanish, Dutch ---------------------------- V 1.7.8 ---------------------------- 1. Italian, Spanish, Dutch language added. 2. Icon for weather serives of WC, WOW and ecowitt added when these services are enabled. 3. New WS90 sensor supported. 4. Max/Min font color changed. 5. Optimized sensor ID page for better logic. 6. Haptic rain data will be stored in flash upon priority selection. 7. Haptic rain gain can be set for different rain intensity. 8. German translation updated for better layout. 9. Tighter new sensor validation check when new sensor type is found. This is helpful in avoid wrong sensor data being recieved. 10. If haptic and tip spoon type rain sensor both present, user can select which data should be used at "more" page. 11. Fixed a bug for pm2.5 sensor not locked for its sensor ID. 12. Special character supported at the key board layout. ----------------------------- V 1.7.7 (courtesy @kheller2) ----------------------------- 1. French Language Supported. 2. SD card status displayed. When there is SD card inside, a SD card symbol will be lit. If the SD card is not readable or writeable, there will be an indicator to tell the SD card status. ----------------------------- V. 1.7.6 (courtesy @kheller2) ----------------------------- 1. The reset weekly rain replaces the option pressure switch, which can chose monday or sunday. 2. The reset daily rain replaces the option background color switch.
Change log for GW2000 firmware V.2.1.1 thru 2.1.9, 2.2.0 thru 3.2.1 versions
V. 3.2.1 - resolves the issue that a registered WN32P was ignored V. 3.2.0 - - Fixed a bug where the pressure value did not change in some cases V. 3.1.9 (18-Jan-2025) - Supports MQTT protocol for the customized server. (so far WebUI only - WSV+ and EW app need to be upgraded) - Supports LDS01 heat count statistics. V. 3.1.8 (18-Dec-2024) - fixed some IoT smart plan bugs. V. 3.1.7 (12-Dec-2024) -Supports use of sunrise and sunset with or without time offset settings for IoT smart plans. -Supports laser ranging sensors (LDS01). -allows to adjust the upload time interval for Weather Underground and WeatherCloud. (so far WebUI and Eowitt app only - WS View Plus needs to be updated for this to work) V. 3.1.6 (26-Sep-2024) - Optimized WS85 and WS90 rain detection algorithm. - Fixed a memory leak issue. V. 3.1.5 (12-Sep-2024) - Supports 16 channels for WH51 soil moisture sensors. - Support WS85 and WS90 rain start detection. - Adjust the upload time interval. V. 3.1.4 (04-Jul-2024) - Optimizes RF reception performance V. 3.1.3 (21-May-2024) - Support WS85 sensor. - Support local web pages (WebUI) to control IOT sub-devices (manual only). V. 3.1.2 (14-Mar-2024) - Fixes a memory leaks and some known crashes. - T&HP sensor can replace indoor temperature, humidity, pressure data. - Fixed a bug when wifi is turned off. V. 3.1.1 (26-Jan-2024) - Fixed bug where some devices could not upload ecowitt. - alternative WH32B (WH32 indoor) can be selected instead of inbuilt sensors. V. 3.1.0 (12-Jan-2024) - Optimize the stability of IOT device WFC01 and AC1100. - Fix the problem that setting parameters may be lost after power off. - Fix the memory leaks and some known crashes. V. 3.0.9 (08-Jan-2024) - Optimize the stability of IOT device WFC01 and AC1100. - Optimized the sub-device offline problem. - Fix the problem that setting parameters may be lost after power off. V. 3.0.8 (16-Oct-2023) - Optimize the stability of IOT device WFC01 and AC1100. - Optimized the sub-device offline problem. - Fixed some known bugs. - removed polling restriction of the WebUI (was limited to 8 seconds 3.0.4-3.0.7) V. 3.0.7 (15-Sep-2024) - Optimized MQTT data upload - Optimized the sub-device offline problem V.3.0.4/3.0.5/3.0.6 (21-Jul-2024, 20-Aug-2023) - Supports IOT device WFC01. - Fixed an issue with incorrect rainfall of ß test version 3.0.2 - Support smart scene function. - Fixed some known bug. V.2.2.5 (15-Jul-2023) - Local web interface added AFC* ON/OFF setting function, default OFF, when the RF is not stable can try to switch it. (only in the WebUI, not planned for WS View Plus !) - Fix some bugs in ip Settings and add DNS server Settings. - Fix some known bugs. *) AFC = automated frequency control V.2.2.4 (31-May-2023) - Fix some bugs in ip Settings and add DNS server Settings. - Optimize wireless RF parameters - Optimization of air pressure data error problem. V.2.2.3 - WLAN can be switched on or off - WLAN can also have a static IP address assigned V.2.2.2 - Fixed a bug that parameter storage is not timely. V.2.2.1 - support remote firmware upgrade - replace "feel like" by "Feels like". - don't show heat index, wind chill V.2.2.0 - Optimize the http server. - Optimize weathercloud server upload. - Wunderground protocol adds support for multi-channel data upload. V.2.1.9 - Optimize exception handling of RF reception - Fix some display problems - Supports the upload of leaf moisture sensor data (refers to WH2682/ObserverIP2.0 - shared WebUI/firmware) V.2.1.8 - Fix the bug of not reconnecting the router (when losing connection - WiFi interface) V2.1.7 - Fix the bug that the RF module may not receive data V2.1.6 - Added password encryption for HTTP transmission - Supports the function of quickly uploading to the server after thunder (ecowitt.net only, custom server not affected) - shows firmware version for a connected WS90 in sensorIDs when hovering the mouse over the icon V2.1.5 - Fix some spelling mistakes - Optimize code to improve stability - Support wh34 calibration - Support temperature correction depending on solar radiation and wind speed for WS69, WS80, WS90 V.2.1.4 - fix static IP issue for LAN interface - repair sensor page power status display. - fix lightning data display in livedata V.2.1.3 1.Fix the bug of daylight saving time algorithm V.2.1.2 1.Fix the correctness of piezo gain upload 2.Fixed that the original number and piezo gain are not transmitted during user customized upload 3.Support user to open or close WI-FI AP mode 4.Repair the display of battery status of all sensors V.2.1.1 1. normal rain gauge data and ws90 haptic rain data can be uploaded at the same time and you can view both rain values on your same dashboard. This gives you the possibility that you can view both rain data from WS90 and WH40(WS69) in parallel. 2. Haptic rain calibration can be adjusted according to different rain intensities. This will make it possible that you can fine-tune the rain accuracy for the WS90 wittboy sensor. 3. pressing the central reboot button for more than 10 seconds will perform a factory reset (earlier a factory reset was not possible)
Change log for GW1100 firmware 2.04 thru 2.09 thru 2.2.3, 2.2.7-2.3.7 versions
V. 2.3.7 (22-Jan-2025) - Supports LDS01 heat count statistics V. 2.3.6 (25-Dec-2024) - removed network incompatibility issue with the 5G ZTE MC801A router V. 2.3.5 (12-Dec-2024) - Supports 16-channel soil moisture sensors - Supports WU and WeatherCloud upload time interval settings - Supports LDS01 laser distance sensors V. 2.3.4 (11-Jul-2024) - Fix the issue of incorrect voltage upload for wh34/wh35/wh68 batteries. V. 2.3.3 - Optimize RF reception performance V. 2.3.2 - Added support for WS85. - Fixed some known bug. V. 2.3.1 - Fixed bug where some devices could not upload ecowitt. - alternative WH32B (WH32 indoor) can be selected instead of inbuilt sensors. V. 2.3.0 - Fix the memory leaks and some known crashes. V.2.2.9 - Fixed some router connection issues and support WPA3. - Support WN34D temperature sensor (-55~125 ℃). - Optimize local web pages. - Fix the problem that setting parameters may be lost after power off. V.2.2.8 - removed polling restriction of WebUI to 8 seconds introduced with 3.0.4 - Optimize local web pages. - Fixed some known bugs. V.2.2.7 - Fixed some router connection issues and support WPA3 - Support WN34D temperature sensor (-55~125 ℃) - Fixed some known bugs V.2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.2.0, 2.2.1, 2.2.3,2.2.5-2.2.6 see GW2000 V.2.2.6 - add WN34D support (temperature -55°C - +155°C) - fix known bugs V.2.1.4 - repair sensor page power status display. - fix lightning data display in livedata V.2.1.3 1.Fix the bug of daylight saving time algorithm V2.1.2 release 1. Fix the correctness of piezo gain upload 2. Support user to open or close WI-FI AP mode 3. Repair the display of battery status of all sensors V2.0.9 release 1.Support scanning WiFi hotspot list 2.Modify sever LED status 3.Fix too many broadcasts V2.0.8 release 1. Optimize distribution network function 2. Fix SNTP function bug 3. Add new version information prompt 4. Support wh25,wh26 data protocol new V2.0.7 release 1. fixed bug for wind speed error on WOW. 2. Lightning data stored locally and the pattern of displaying has been updated. 3. rain reset time is user define enabled now. 4. Sensor data priority has been changed so that wh40 will override WS65,69, WS90. V2.0.6 release 1、change sntp time update from once per day only to every one hour 2、fix rain month no reset bug. 3、fix bug for wow wind speed upload error. V2.0.5 release 1、fix web live data page for invalid data of co2, pm25 handling. 2、upgrade WIFI(server led) status: 1)off - no router connected. 2)on - data has been published to server successfully. 3)flash 1hz router connected, but not able to publish data to weather server. V2.0.4 release 1、support new sensor WH90 2、HTTPD web server turned on 3、change RF chip AFC:0x8F :AFC OFF to 0x9F:AFC ON. 4、update soil ad setting page
Change log for WN1900/WN1910 firmware V.1.2.2 thru 1.2.4 versions
V.1.2.4 - Support WN34D temperature sensor (-55~125 Celsius) - Support WH46 air quality sensor - Wi-Fi transmission power increased for better connectivity - Fixed some known bugs V.1.2.3 bug fixes in weather forecast V.1.2.2 Optimize LCD screen for barometric and rainfall Wunderground protocol adds support for multi-channel data and piezoelectric rain upload
Change log for WN1920/WN1980 firmware V.1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.2.3, 1.2.7 thru 1.3.5 versions
V. 1.3.5 (17-Jan-2025) - Supports LDS01 laser distance sensors. - IoT Smart supports new triggers and actions. - Optimized router reconnection after disconnection. V. 1.3.4 (19-Nov-2024) - The HTTP Local API (get_livedata_info) now includes debug information (heap, runtime, interval [custom server]) - Optimized Wi-Fi station driver - Fixed memory leak issues V.1.3.3 (08-Nov-2024) - supported 16-channel soil sensors - supported WS85 and WS90 rain state detection - supported local web pages to control IoT sub-devices - fixed some known bugs V.1.3.2 - Optimize RF reception performance. - The TCP/IP protocol supports obtaining the heap size information. V.1.3.0 - Added support for WS85 wind and rain sensor. - Added support for automatic backlighting of web page control. - Only battery power no longer turns on wifi function to reduce power consumption. V.1.2.8 - Supports IOT device WFC01 and AC1100 - T&HP sensor can replace indoor temperature, humidity, pressure data - Fixed some known bug V.1.2.7 - T&HP sensor can replace indoor temperature, humidity, pressure data Fixed some known bug V.1.2.3 1. Supports IOT device WFC01 and AC1100 2. Supports smart scene funtion 3. Support display outdoor temperature and humidity to WN182x screen V.1.1.4 1. Add setting items: ON/OFF the LCD screen INDOOR display area to display multi-channel sensor data. (For WN1820/WN1821, default OFF) 2. Fixed weather forecast bug.(For WN1980/WN1920) V.1.1.3 1. Wi-Fi icon display indication: a. Fast flash: Wi-Fi provisioning b. Slow flash: Without internet c. Not display: Not connected to router d. Hold display: Normal 2. Fixed some known bug V.1.1.2 1. Fixed incorrect outdoor temperature and humidity values in HiLo mode. 2. Fixed some known bug. V.1.1.1 1. Optimize the display of browser tab icon in web pages. 2. Wunderground protocol adds support for multi-channel data upload. 3. Fixes some known bug.
Change log for WN1820/WN1821 firmware V.1.2.3, 1.2.7 thru 1.3.5 versions
V. 1.3.5 (17-Jan-2025) - Supports LDS01 laser distance sensors. - IoT Smart supports new triggers and actions. - Optimized router reconnection after disconnection. V.1.3.4 (19-Nov-2024) - The HTTP Local API (get_livedata_info) now includes debug information (heap, runtime, interval [custom server]) - Optimized Wi-Fi station driver - Fixed memory leak issues V.1.3.3 (08-Nov-2024) - supported 16-channel soil sensors - supported WS85 and WS90 rain state detection - supported local web pages to control IoT sub-devices - fixed some known bugs V.1.3.2 - Optimize RF reception performance. - The TCP/IP protocol supports obtaining the heap size information. V.1.3.0 - Added support for WS85 wind and rain sensor. - Added support for automatic backlighting of web page control. - Only battery power no longer turns on wifi function to reduce power consumption. V.1.2.8 - Supports IOT device WFC01 and AC1100 - T&HP sensor can replace indoor temperature, humidity, pressure data - Fixed some known bug V.1.2.7 - T&HP sensor can replace indoor temperature, humidity, pressure data Fixed some known bug V.1.2.3 1. Supports IOT device WFC01 and AC1100 2. Supports smart scene funtion 3. Support display outdoor temperature and humidity to WN182x screen
Change log for WS6006 firmware V.1.1.30 thru 1.1.37
V.1.1.37 - Supports the AIR795U 4G module - Fix the APN setting error of the UC20UC15 module V.1.1.36 - Supports the AIR795U 4G module V.1.1.35 - Fixed SMS Alarm function V.1.1.33 - Optimize the power consumption of the VA module V.1.1.32 1. Support for a WS80 ultrasonic wind speed sensor array 2. Support for a WH40 rainfall sensor 3. PC software must be V1.7.1 or later V.1.1.30 1. Added support for a WN34 temperature sensor 2. Added support for a WN35 leaf wetness sensor 3. Added Sensor ID setting screen to PC software 4. PC software for update etc. must be V1.6.9 or later
Change log for EasyWeather WiFi firmware V.1.6.7 thru 1.6.9 versions
V. 1.6.9 - fixed some bug V. 1.6.8 - support WS85 sensor - removed bug not showing WS90 capacitor voltage on ecowitt.net/Customized Server V. 1.6.7 - Support WN34D temperature sensor (-55~125 °C) - Support WH46 CO2 sensor (pm1.0/pm4.0) - Supports the upload of leaf wetness sensor data
Change log for EasyWeatherPro WiFi firmware V.5.1.3 thru 5.1.7 versions
V. 5.1.8 - Support for more sensors. (depending on reseller) - Solved ZTE MC801A router incompatibility. V. 5.1.7 - fix the local web page may not open in ios18. - fix some known bugs V. 5.1.6 added support for WS85 data V. 5.1.5. fixing unwanted restarts, especially on consoles with low memory (e.g. WS2320E [WH4000SE] and WS2910 [WH3000SE]) and new WiFI modem V. 5.1.4 - fixed loss of settings at restart - fixed a memeory leak V.5.1.3 support WN34D sensor
Change log for WiFi firmware AMBWeather V.4.3.5 versions
V. 4.3.5 1. Supports the upload of leaf wetness sensor data 2. Fixed a bug in WH30 where incorrect humidity was uploaded 3. Fixed some known bug.
————————————————————————————————————————————————————————————–
Change log for WiFi firmware AMBWeatherPro V.5.1.5 thru 5.1.7 versions
V. 5.1.8 1. Support for more sensors. (depending on reseller) 2. Solved ZTE MC801A router incompatibility. V. 5.1.7 support 8-channel CO2 sensors V. 5.1.5 1. Supports the upload of leaf wetness sensor data 2. Fixed a bug in WH30 where incorrect humidity was uploaded 3. Fixed some known bug.
————————————————————————————————————————————————————————————–
firmware downgrades
firmware downgrades
in certain cases it could be necessary to downgrade to an earlier version of the device firmware.
- HP25x0 –> copy user.bin of earlier version on a microSD and insert into the console
- GW1000, GW1100, GW2000, WH2640, WN19x0, WS3800, WS3900
this is a more complex procedure which we will describe separately
see
firmware downgrade of the consoles with local Ecowitt network API ("telnet")
downgrade of the WiFi firmware
to be completed
WiFi firmware downgrade
—————————————————————————————————————————————————————————————–
7. Acronym Scheme for stations, consoles and sensors
Ecowitt
consoles end in “0”, exception WN1821
sensors and arrays end in any number - 0 - 9
stations (=console + sensor(array)s) have an ending scheme which defines the array used in the station
- “1” means with a WS69 array - exception WN1900
- “2” means with a WS68 array - or with a WS85 array for the WS3800/WS3900/WS3910 consoles
- “3” means with a WS80 array
- “4” means with a WS90 array - exceptions: GW2001, WN1981, GW1104 (just the gateway and a WH31 sensor)
the first two starting letters (console, sensor, station)
HP xxxx weather station with a console TFT color panel, e.g. HP2551
WS xxxx weather station with solar panel, e.g. WS2320
WH xxxx weather hub (old[er] stations), e.g. WH1080
WN xxxx weather station without solar panel, e.g. WN1900 or battery-run sensors e.g. WN34L *)
GW xxxx gateway series, e.g. GW1000
*) the WN use for stations is not consequently maintained, especially in the WN18xx, WN19xx series, as there are stations offered together with a WS90 which has a solar panel
exceptions:
the WH2320E/WH2350E using the WH65/WH69E has a solar panel (meanwhile renamed to WS2320E and WS69)
the WH2650 WiFi [sold by Fine Offset only or by European resellers (868 MHz)] is also a gateway console
the WH0290 Air Quality Monitor is not a full-fledged weather station. It's a console for one WH41/WH43 PM2.5 sensor
the WN1980 console comes as WN1981 station with the WS90 which has a solar panel (the 1st WN19x0 (x=0,1) stations originally came with the WN67 which has no solar panel, hence the “N”)
XXnn[nn]A, XXnn[nn]B, XXnn[nn]C A= 868 MHz model, B=915 MHz model, C or nothing=433 MHz model. e.g. HP2551A
(exception: WH0300B, station is only transmitting at 433 Mhz)
further differentiation:
S: soil, L: water (liquid), B: barometer (WH32B = like WH32 T/H outdoor but indoor + B = WH32B (indoor))
P: Pressure (WN32P [new name] = WH32 indoor = WH32B [old name])
e.g. WN34AS = 868 MHz, soil temperature sensor; WN34BL = 915 MHz, water temperature sensor
E: extended edition (e.g. WH2320E), SE: special edition [Froggit only] (e.g. WH3000SE, WH4000SE, HP1000SE)
numbering:
The last number of the model number usually refers to the product development time order. e.g. The GW1002 is developed after the GW1001 and has a different composition - it also indicates the array used with station kits.
(that's a marketing thing: from GW1001 through GW1003 new console/sensor combinations are offered - see also below under packages)
The GW1000 console in these packages is the same.
Froggit
all weather stations (console + sensor array + indoor sensor where applicable) start with either WH or HP
all extra sensors and gateways fall under their DP series (including the DP1500 which is the rebranded GW1000/GW1100 and the DP2000 which is the rebranded GW2000)
Ambient
all weather stations start with WS, extra sensors are either WHxx or WSxxxx-SENSOR (SENSOR is usually ARRAY or RAIN etc)
————————————————————————————————————————————————————————————————-
Calibration
Even though manuals and people speak in the context of sensors of calibration, in the context of sensors of weather stations it would be better and more precise to speak of adjustments.
Calibration is done with sensors, adjustments happen in consoles.
What is named calibration in the manuals always takes place in the console and therefore is an adjustment and not a calibration.
It has become common use to (wrongly) speak of calibration - so we will do this here too, at the same time being aware that we only do adjustments.
8.1 How to calibrate the air pressure of your console (barometer)
most consoles have an inbuilt barometer chip (WS2320E, WH2910, HP350x, GW1x00, GW2000), the HP2551 console uses an external combo sensor, the WH32B temperature, humidity, air pressure sensor. (for the Ambient names of the consoles, sensors mentioned have a look at the console/sensor matrix)
We will describe here a simple procedure without going too much into the technical and scientific background and which will result in a fairly good calibration of your barometer.
If you want to deep dive into the matter, fine tune your readings etc, there are quite a few posts in the Ambient Weather and Ecowitt and other Fine Offset clones board at wxforum.net, which can take you further into the matter e.g. https://www.wxforum.net/index.php?topic=43477.0 (“beginners”) or https://www.wxforum.net/index.php?topic=43602.0 (more advanced - the author says “intermediate”) The author of these posts has also provided a very encompassing walk through the topic here: see Barometer
The best conditions for doing this calibration would be a sunny day with an outside temperature around 15°C/59°F. For better accurcy you should do the calibration using hPa (hectopascal) units and not mmHg. (If you prefer to see the pressure display in inHg, you can change the display units of your console once the calibration is completed).
Basically your air pressure sensor measures the air pressure at the place where the sensor (in most cases the console) is located. This is also called the absolute air pressure. This air pressure changes with the altitude above sea level, as the weight of the air become less the higher you go (as there is less air to create the pressure above). In order to make this air pressure comparable with other places, it is put in relation to the air pressure at sea level. The air pressure at sea level is standardized to be 1013.25 hPa or mbar at 15° C. The local, absolute air pressure put into relation with the sea-level pressure is called relative air pressure. What we need to do is to find the relative pressure which corresponds to the absolute pressure of your (sensor's) place.
For this you need two things:
1. the altitude of your (sensor's) place above sea level (ground level [elevation] + height of the barometer above ground [height] = altitude)
2. a calculator which converts this altitude and the absolute pressure of your location into the relative pressure.
we will use: https://www.starpath.com/barometers/baro_cal.php
MSL = Mean Sea Level
in the picture above just replace the airplane with your console
Here you have three values to enter: (1), (2), and (3)
- get your elevation (find out from e.g. https://www.randymajors.org/elevation-on-google-maps or similar tools)
- add your height to your elevation to get your (console) altitude (1)
- your absolute air pressure provided by your console (2)
- the actual temperature (3)
(in a more sophisticated approach you use the average temperature between actual and the temperature 12 hours ago) -
why the local average temperature is used ? see also Air Pressure correction
for demonstration purposes we will assume the following values:
elevation 243 m, absolute air pressure 994.0 hPa, temperature 15°C
entering these values into the calculator at https://www.starpath.com/barometers/baro_cal.php and pressing the “Compute SLP” button,
will provide a sea level pressure of 1,022.9 hPa and an offset of 28.9 hPa (or mb) (rounded to one decimal place).
This is what you have to enter into the “relative Offset” field in your console. Of course you will have to take your 'personal' difference resulting from your values (altitude, absolute presure). Once done and saved you are set.
Consoles with the local Ecowitt Gateway API can be configured/calibrated with the WS View Plus app, or, if available, with the inbuilt console WebUI.
The HP25x0 consoles have to be calibrated inside - on their calibration page ( 3 x Gear Wheel *). Here you don't have to enter the offset but the actual relative (or absolute, if you want to correct the local pressure) value has to be entered = take the SLP value the calculator provided.
*) attention - the position of the gear key shifts after the first press one key to the left !!
If you want to further fine tune your calibration, e.g. comparing with a the so-called METAR of a near-by airport
(not too far away, +/- similar altitude as your place !),
you will need to look up the sea level pressure (rel. pressure) from that airport and compare it with your relative air pressure.
If there is a difference, you can enter this difference (+ or - !!) into the “absolute offset” field in the calibration menu.
If the pressure at the airport is higher, you have to enter the difference as a positive offset,
if it is lower, as a negative absolute offset.
The Absolute pressure Offset method (normalized Sea Level Pressure [SLP] = Station pressure (absolute/local pressure) plus Offset is a rather simple approach. As temperature changes also the offset changes.
Ideally the console would calculate regularly the SLP from the locally available values as the online calculators do and update either the offset or right away the relative pressure.
Note:
comparing data, especially air pressure, with your neighbouring private weather stations can be tricky - because who knows if their owner has calibrated the relative pressure properly or not. Taking an offical public weather station located at the same height might be more advisable.
If you have subscribed (free) to the AWEKAS* weather service and post your station data also there, AWEKAS offers a comparision option for AWEKAS-registered stations in a 10, 10, 50, 100 km radius, which can give you some idea about the correctness of your calibration.
*) AWEKAS is an Austria based weather service. AWEKAS stands for “Automatisches Wetterkarten System” - that's German for Automated Weather Map System. By the way one of the very few Weather Services where you can retroactively upload data and where your uploaded data can be retroactively corrected.
with device firmware 2.0.0 of the HP25x0 console user life will become easier and at the same time air pressure data will become more accurate. The user will only have to provide the altitude of the station barometer. Then the SLP is calculated and updated at every change of the parameters outdoor temperature, humidity and local station pressure (ABS) - the feature will be rolled out to most of the other consoles.
the formala used is: sea_level_pressure_calculation.pdf
Again, for more details, look up e.g. https://www.wxforum.net/index.php?topic=43477.0 or other air pressure calibration discussions in this WiKi.
the automatic SLP update feature with device firmware 2.0.0 has also been tested on Ambient WS-2000/4000/5000 consoles and works there also - the REL pressure field is repurposed to an altitude field
Alternative elaborations by an “air pressure adept” can be found here:
Barometer
————————————————————————————————————————————————————————————————-
9. sensor battery status, values etc.
WH24 = the boat; WH26 = WH32 outdoor/WN32; WH25 = WH32 indoor/WN32P
the WH46 values are the same as for the WH45
the WS69/WH65, WH80, WS85 and WS90 arrays have two AA batteries as backup
the WH31/WN30, WH32, WH41, WH43, WH45, WH46, WH57 sensors have two (the WH41 rechargeable) AA batteries for power supply
the WH55 sensor has two AAA batteries
the WN36 has an inbuilt not replaceable batterie
all other sensors (WN34, WN35, WH40, WH51, WH54 (LDS01)) have one AA battery for power supply.
————————————————————————————————————————————————————————————————-
10. data flow between sensors, consoles, application software and internet weather services
popular examples for templates are Weather34 (stand-alone or e.g. inside Meteobridge on Raspi), Meteotemplate, CumulusMX default web site or pwsDashboard (which could also be directly fed from a console or e.g. FOSHKplugin)
for examples, see live examples of templates, skins, customized websites etc.
The Android app PWT (Personal Weather Tablet) is often used with the displayless consoles GW1x00, GW2000, WH2650
via their http custom server post (push) function to display their data on an (old or new) Andoid tablet.
To display the Piezo rain data from a WS90 a converter like FOSHKplugin is needed as PWT cannot handle the WS90 rain data yet.
another way to describe the data flow is the (extended) Ecowitt Data Process
- sensor, sensor array
- console/gateway/hub (between RF-network and local network, or LAN and IoT network)
(not to be confused with the gateway between LAN/internet in the network router) - WS View Plus app for local console and IoT device management
- Ecowitt app for cloud data display and IoT device configuration
(connection must be established via the internet first (!) before local activities are possible) - Ecowitt cloud user account and data storage
- weather networks and 3rd party apps (e.g. SmartMixin)
- data logging apps in local network or home automation applications (e.g. HomeAssistant)
- local hosts (e.g. RaspberryPi, NAS server, …) with custom/user web pages/templates (e.g. PWS Dashboard)
- web host with custom/user web page(s), templates (e.g. Meteotemplate)
————————————————————————————————————————————————————————————————-
10a. the Ecowitt console/gateway WebUI (webpage)
The following consoles have a web(page) based user interface (WebUI):
console | configuration | remark |
---|---|---|
WS2320 | weather services only - other configuration inside the console | (with new modem only) |
WS2910 | weather services only - other configuration inside the console | (with new modem only) |
HP2550 | weather services only - other configuration inside the console | (with new modem only) |
HP2560 | weather services only - other configuration inside the console | |
HP350x | weather services only - other configuration inside the console | (with new modem only) |
GW1100/GW1200 | full configuration | |
GW2000 | full configuration | |
GW3000 | full configuration | |
WN182x/WN1920/WN1980 | full configuration | |
WS3800/WS39x0 | full configuration | |
WS6210 | full configuration |
the WN1900/1910 consoles don't have a WebUI, however, they can be fully configured via the WS View Plus app.
the GW1000 and WH2650 and the consoles with the old WiFi modem can only be configured via WS View Plus or the awnet app for Ambient branded consoles (see there WiKi)
the following Ambient consoles/gateways also have a WebUI (same style as Ecowitt)
console | configuration | remark |
---|---|---|
WS-2000 | weather services only - other configuration inside the console | (with new modem only) |
WS-4000 | weather services only - other configuration inside the console | (with new modem only) |
WS-5000 | weather services only - other configuration inside the console | (with new modem only) |
WS-2902D | weather services only - other configuration inside the console | (with new modem only) |
WS-1965 | full configuration | |
WH2682 | full configuration | (WeatherHub, ObserverIP 2.0) |
(the WS-2000, WS-4000 and WS-5000 consoles are technically identical consoles, they only have a different product number - and show a different model name on the“Factory” –> “About[Display]” page as it is the case with every reseller model)
These consoles can also be accessed inside the local network by entering their IP address in the URL field of a webbrowser -
e.g. https://192.168.1.22.
The access is done via the http API (see http API)
before pairing with the router in the local network (or in order to do the pairing) all consoles have their own WLAN (“WiFi Access Point”) which is used for the pairing process. It can also be used during operation as long as the access point is activated (can be switched off in most consoles). The SSID of that access point is either EasyWeather-WIFIxxx or EasyWeatherPro-WIFIxxxx or e.g GW2000A-WIFIxxxx (console name + region + text WIFI + last 4 digits of the MAC address) - or AMBWeatherPro-xxxxxx or WS1965B-WIFIxxxx/WH2682B-WIFIxxxx for Ambient consoles) and the console has there the IP address 192.168.1.4. Your computer/smartphone will have to connect to that network to operate the console this way.
consoles with new WiFi modem
consoles with local API only
by the way - the red dot at the Devices Settings menu item means that new firmware is available
sensor registration and disabling for consoles/gateways with the local Ecowitt API is done on the sensors ID page
10b. the WS View Plus, the Ecowitt and the Ambient Weather Network apps
there are four FineOffset/Ecowitt apps available for some of which some of the resellers claim to be there own app which they aren't.
app name | status | latest version | remarks / availability |
---|---|---|---|
WS Tools | depreciated | —- | does not work with modern FineOffset/Ecowitt WiFi stations |
WS View | depreciated | Aug-2023 | still available in the Google/Apple store, but does not work with the WS90 sensor array, the GW1200 or the new WS3800/WS39x0 consoles |
WS View Plus | actual | 2.0.49 | available in Google/Apple app store last version working with Ambient consoles: 2.0.48 |
Ecowitt app | actual | 1.1.28 | available in Google/Apple app store |
awnet app | actual | ????? | available in Google/Apple app store |
Ambient Weather Osprey tool | depreciated | ????? | available in Google/Apple app store |
Ambient Weather Network app | actual | 12-Jan-2024 | available in Google/Apple app store |
for on overview on the differences between the WS View Plus app and Ecowitt app see app comparison
WS Tools
WS Tools
there are still older reseller manuals sold with Fine Offset / Ecowitt clone weather stations which wrongly claim that the WS Tools app is used to connect/pair and configure the weather station.
This was true for very early (old) Fine Offset weather stations but is no longer the case with the recent (>2019) models.
The WS Tools app, no longer available in the Google or Apple app store, simply cannot do this any more. Instead one would need to use the WS View (Plus) app.
WS View
WS View
The WS View app (depreciated, not supporting all sensors) is the predecessor of the WS View Plus app which was used for pairing, firmware upgrade, configuration, calibration, configure Weather Service postings including the Customized Server - and for consoles with the local gateway API also displaying live data. The Weather Undergroud (WU) dashboard could be displayed for a list of to be entered WU station keys.
When connecting a console for the first time (device list empty), the following picture/page will be shown:
(when connecting to a new device with WS View, you only have the old, limited console selection options)
When at least one console has been connected, the following picture/page appears:
Most users would find only one entry in their device list (as they have only one device = console).
After selecting the device from the device list the page shown would be the weather network configuration for consoles without the local gateway API and the Live Data page for the consoles with local gateway API.
Except for the display of the WU dashboard, the smartphone/tablet needed to be connected to the same local network the consoles were in.
The WS View app (last update 10-August-2023) does not support all consoles - and all sensors neither.
- live data of a GW1200 is shown, but the SensorIDs cannot be shown
- for a WN1980 no live data is shown - only the WiFi firmware portion (Weather network configuration)
- the new WS3800/WS39x0 consoles are not shown at all (no live data/no Weather networks)
- for consoles where sensor IDs are shown, the WS90 is not shown and piezo rain cannot be configured
Recommendation: use the WS View Plus app instead
(if the full functionality is needed)
WS View Plus
WS View Plus
The WS View Plus app is the latest edition of the WS apps from Fine Offset/Ecowitt. The actual version (16-Nov-2024) is 2.0.52.* It supports all consoles and sensors of the Ecowitt ecosystem with the exception of the creation of smart plans of the IoT devices (so far WFC01 and AC1100, December 2024) and the inbuilt CO2 sensors of the WN1821 and WS3910 consoles.
*) the undocumented and inofficially still possible support of Ambient consoles was only possible up to version 2.0.48 and was removed with version 2.0.49.
an apk file for Android version 2.0.48 is available here: WS View Plus 2.0.48 apk
(WS View Plus 2.0.48 does not support the WS85 3-in-1 sensor !!)
The IoT devices were originally only handled via the Ecowitt app.
Meanwhile, since version 2.0.49, manual management is also possible via WS View Plus and the WebUI of the console the IoT device is connected to.
As the Ecowitt app cannot handle consoles in the local network independent from the internet, it is planned to also empower the WS View Plus app in the future to manage the IoT devices.
functionalities of WSV+:
- pairing of a console with the local WLAN network and its router
- configure Weather Service postings including the Customized Server
- firmware upgrade (WiFi firmware or combined firmware) see Firmware
- display the WU and Ecowitt Dashboards for stations registered with wunderground.com (all) and ecowitt.net (own only)
and, for consoles/gateways with the local gateway API, also allow for
- configuration
- calibration
- display of live data
The Weather Underground (WU) dashboard could be displayed for a list of to be entered WU station keys.
Here only the station ID is needed to be entered into a list of WU station which then can be displayed. No password is needed here.
The device list of WS View Plus (WSV+)
If one or more consoles are registered in the same network, they appear in the device list of the app (Device List).
The device list or favourites list is the start screen of the WS View Plus app.
It comes with a blue star at the right end of each device entry. After tapping on that star you can select a matching symbol and a custom name for your console and it will then appear in the Favourites list.
An entry in the device list consists of the console name (for GW1000, GW1100, GW2000, WH2650, WN19x0) with frequency identification (A=868 MHz, B=915 MHz, nothing=433 MHz) and the last four characters of the MAC address as well as the firmware version. This is followed by the IP address and MAC address. In the favourites list, you can also assign a device name (Device:). For consoles without GW1000-API, EasyWeather or EasyWeatherPro (HP2560 or 2nd generation HP2551) and the version of the WiFi firmware (EasyWeather[Pro] is the name of the WiFi firmware) are displayed instead of the console name.
EasyWeather(Pro)-WIFIxxxx or GW1000A-WIFIxxxx (etc. for the individual consoles) is also the name of the SSID of a network that the console sets up/uses during the pairing process so that it can be informed of the SSID of the WLAN access point to the local network and the password so that the console can log in there and obtain its IP address.
For the consoles with EasyWeather(Pro) entries in the device list only the Weather Services pages for Ecowitt, Wunderground, WeatherCloud and WOW are shown after tapping on the device list entry. Live data viewing and device configuration can only be done with consoles which have the local Ecowitt API.
The live data page comes with several tabs - on the main page you see the basic sensors outdoor and indoor temperature and humidity, local and relative air pressure (SLP), the solar data, wind data including the maximum gust of the day. Then come the rain data. When a WS90 is connected and a second traditional rain sensor as well (WS69, WH40), both sets of rain data, traditional and piezo, are shown one under the other. Next comes the lightning sensor. For each separate sensor its sensor ID, the signal quality (how many data packets successfully received) and the battery status is shown. The main page completes with the air qualty sensors (WH45 and WH41/43) and the water leak sensors (WH55).
the second tab shows up to eight extra temperature/humidity sensors (WH31 family)
the third tab shows up to eight the soil mositre sensors (WH51/WH51L)
the fourth tab shows up to eight user temperature sensors (WN34L/S/D)
the fifth tab shows up to eight leaf wetness sensors (WN35)
you can move between the tabs either by tapping on the tab text or by tapping on the arrows in the left and right corners.
Tapping on the top right button “More” opens a menu with access the further pages for calibration and configuration.
The calibration of the rain gauges including the five tier calibration of a WS90 is done on the “Rain total” page.
To display one's stations in the
Ecowitt dashboard of WSV+,
the respective console has to be bound to the Ecowitt cloud.
This is done by accessing the Weather Services page in WSV+ of the console you want to bind via the device list (Device list entry –> Live Data –> More –> Weather Services) for consoles with the local Ecowitt API. With the other consoles without API you will directly find yourself on the Weather Services page. On that page you have the ecowitt.net posting setup and a button “Bind to Ecowitt”. After pressing this button you have to enter your account credentials (email + chosen password) and then press next.
As a result the Ecowitt dashboard page of your console will be displayed, the same view which you have in the Ecowitt app. What is shown are the one minute data the console posts to ecowitt.net. If you have more than one device, you can bind them one by one. When you tap on “Ecowitt dashboard” icon on the bottom task bar, you will be connected to the first entry in the bound Ecowitt device list. You can change to another of your devices by tappig on the “Devices” button top right.
you basically get the same display as from the Ecowitt app - without configuration options (e.g. IoT subdevices)
WS View Plus is mainly a tool for local device management including manual IoT device management. Every activity is performed inside the local network without the need for internet access as it is with the Ecowitt app. Only with WSV+ and the WebUI real time data can be viewed on the Live Data page. The Ecowitt app only provides minute data as WSV+ does in the Ecowitt dashboard view.
Only for the optional use of the WU and Ecowitt dashboards, internet access is needed.
⇒
the WSV+ app can also be used for weather station viewing outside the local network, from any loction with internet access.
technical background information: (you need to have read and understood the local Ecowitt API → table of contents)
it appears that while the WS View app was retrieving gateway info (e.g. live data) from the GW1000/WG2650 devices via the tcp/ip protocol (aka telnet protocol) and port 45000 (mainly), this has changed for WS View Plus and the more modern devices. While GW1000 and WH2650 and WN1900/1910/1920 are still queried via the tcp/ip protocl (Ecowitt speech: “telnet”), the modern gateways which all possess an inbuilt webserver (WebUI) [WN1980, WN182x, GW1100, GW1200, GW2000, WS3800, WS3900, WS3910, WS6210) are queried via the http protocol. The http API is almost identical to the “telnet API”. A few “fluctuations” in variable names (markers to retrieve dedicated information) have been reported, especially with the markers for wind chill and feels like.
even the telnet API has not been fully documented by Ecowitt. So can the newly introduced PM1/PM4 data of the WH46 be retrieved when it is connected to a GW1000 - via marker 0x6B (which was depreciated earlier). The data area following marker 0x6B is 16 bytes longer than the area following marker 0x70 for a WH45 which has no PM1/PM4 data.
WS View Plus and the WebUIs obviously know this marker as they retrieve and display the PM1/PM4 data via the http getlivedata command.
Ecowitt has recently (12-Dec-2024) published a basic WSV+ / WebUI manual
Ecowitt app
Ecowitt app
latest version: 1.1.51 (03-Jan-2025)
Simply speaking the Ecowitt app is nothing else but a web browser app which displays the data from ecowitt.net in one (smartphone) or two to three columns (tablet) instead of more columns and more horizontally oriented like the Ecowitt dashboard in a standard web browser on a computer.
It uses the same tiles and graphs as the Ecowitt dashboard in the web browser.
Inside the local network it can also configure (like the WS View Plus app) devices (consoles/gateways) which have the local Ecowitt network API. It can, however, not display live data as the WS View Plus app does.
In addition it is so far (March 2024) the only application which is able to fully configure and manage the IoT devices (manual, scheduled plans, smart plans) - so far the WFC01 intelligent valve and the AC1100 intelligent plug. Manual (via app) IoT device management can also be performed with the WS View Plus app (version >= 2.0.49) inside local network.
In order to display your console postings you have to log into your ecowitt.net user account on the app.
Until now (March 2024) the Ecowitt app is the only tool to configure the IoT devices (see picture below, menu item “subdevice” - further details at the respective IoT devices
If the Ecowitt app is connected to the internet and logged into your personal account at ecowitt.net - and is at the same time connected to the same LAN/WLAN as your local devices (consoles/gateways), then also console configuration of console which have the local Ecowitt API can be made. Otherwise the configuration items in the menu (top right) will be greyed out.
awnet app
awnet app
the Ambient Weather app is just the Ambient version of the WS View app, only that it is limited to WiFi firmware upgrade and Weather Service configuration.
Live data cannot be displayed as the WS-2000/WS-5000 console doesn't have the local network gateway API.
Theoretically, the awnet app could be able to read the live data of a WS-1965 console (which is a Ecowitt WN1980 clone), but the same limitations like for the WS View app and a WN1980 console may apply; i.e. only Weather Service and WiFi firmware upgrade are possible.
The same might be true regarding the WH2682 console/gateway - the Ambient ObserverIP 2.0 module or Weather Hub).
To be verified.
The WS View Plus app is able to read the WS-1965 and WH2682 live data though.
This may change in future as it is not an Ambient requested feature.
Ambient Weather Osprey tool app
Ambient Weather Osprey tool app
the app was meant to deal with the WS-2902 console only (Ambient WS-2920 = Ecowitt WS2910) für Weather network configuration and for pairing with the router.
it is meanwhile depreciated
Ambient Weather Network app
Ambient Weather Network app/dashboard - AWN app
The Ambient Weather Network app corresponds to the Ecowitt app.
When an Ambient branded console/station is purchased, this includes a license for registering your console at ambientweather.net and use their services. The AWN app provides and displays data from ambientweather.net. This is your own data, station data in the Ambient Weather network and weather forecast. The app is available at the Apple and Google stores as iOS and Android version.
—————————————————————————————————————————————————————-
10c. the Customized Server feature of the Ecowitt consoles
for Ambient consoles old (WS-2902A-WS2902C, WS-2000 old, WS-5000 old) see awnet app, for new WS-2902D, WS-1965, WS-2000 and WS-5000 see ABMWeatherPro
each Ecowitt (clone) console can post its readings after processing to up to five major (= most known) preset Weather Networks or Weather Services:
Ambient consoles: | ambientweather.net, Weather Underground/wunderground [WU], WeatherCloud [WC], and a freely chosen customized server address (e.g. WU, WC, WOW, custom) |
---|---|
other Ecowitt clone consoles: | ecowitt.net, Weather Underground/wunderground [WU], WeatherCloud [WC], UK Met Office Weather Observation Website [WOW] and a freely chosen customized server address |
If and where you posts to can be set
- in the console (HP25x0/WS-2000/WS-5000)
- in the console WebUI if the console has an integrated webserver (with the new WiFi modem, WN1980/WN182x, WS3800/WS39x0)
- in the WS View Plus app (device list –> Weather Services, or device list–> Live Data –> More –> Weather Services)
the Customized server option can be used to post data to a user chosen domain/IP address in either the local network or in the internet
(hence: Customized)
three (respectively two for Ambient consoles) protocols can be chosen: Ecowitt, Wunderground and MQTT respectively Ambient and Wunderground
the page looks like this example ———————————————–>
six things need to be done to make the console post to the desired server (address)
- enable the posting
- choose the protocol
- enter the domain name or the IP address of the server
- enter the path where the data will be delivered at the receiving server
- enter the port number
- enter the posting interval
Remarks
2. | the protocol is a definition of how sensor names and values are posted - for a description and example for the Ecowitt protocol see below |
3. | only the domain name, subdomain name or the IPv4 IP address must be entered - NO http:// or https:// - the console firmware will put a http(s):// in front of the domain name/IP address itself |
4. | at least a “/” needs to entered here - otherwise the console won't post - what needs to be put here is defined by the application on the receiving server |
5. | a port number must be entered depending on the receiver end - e.g. 80 for standard http or 443 for standard http posts - user defined ports usually start from 8000 on |
6. | accepted intervals are 8 - 600 seconds [10 minutes] |
the Ambient version of the WS View (Plus) app is called awnet (Ambient Weather Osprey tool) app
Ambient consoles post in either Ambient protocol or WU (Wunderground) protocol
for the new hardware revisions of the Ambient WS-2902 (=WS-2902D), WS-1965, WH2685 (Weather Hub, ObserverIP 2.0), WS-2000 and WS-5000 consoles an inbuilt web page (WebUI) is used which can be reached via http://IP-address-of-console in a web browser.
for posting to WU (wunderground from an Ambient console, see below often used weather services via Customized Server
below the maximum number of sensor values for the Ecowitt protocol (status: November 2024) which could be sent if all existing sensors were connected to the allowed maximum
# | sensor name | ## | sensor name | ### | sensor name |
---|---|---|---|---|---|
01 | PASSKEY | 34,36,38,40,42,44,46,48 | tempf1,….,,tempf8 | 138 - 141 | leakbatt1, …,leakbatt4 |
02 | stationtype | 35,37,39,41,43,45,47,49 | humidity1,….,humidity8 | 142 | srain_piezo |
03 | runtime | 50,52,54,56,58,60,62,64 | soilmoisture1,….., soilmoisture8 | 147 - 154 | tf_batt1, …., tf_batt8 |
04 | dateutc | 51,53,55,57,59,61,63,65 | soilad1,…., soilad8 | 155 | co2_batt |
05 | tempinf | 66,68,70,72 | pm25_ch1, …., pm25_ch4 | 156 - 163 | leaf_batt1, …, leaf_batt8 |
06 | humidityin | 67,69,71,73 | pm25_avg_24h_ch1,…..,pm25_avg_24h_ch4 | 164 - 167 | ldsbatt1 ….ldsbatt4 |
07 | baromrelin | 74 | tf_co2 | 168 | ws90_batt |
08 | baromabsin | 75 | humi_co2 | 169 | freq |
09 | tempf | 76 | pm1_co2 | 170 | model |
10 | humidity | 77 | pm1_24h_co2 | 171 | interval |
11 | winddir | 78 | pm25_co2 | 172 | heap |
12 | windspeedmph | 79 | pm25_24h_co2 | 173 - 176 | thi_ch12),…thi_ch4 |
13 | windgustmph | 80 | pm4_co2 | 177 - 180 | depth_ch13),…depth_ch4 |
14 | maxdailygust | 81 | pm4_24h_co2 | ||
15 | solarradiation | 82 | pm10_co2 | ||
16 | uv | 83 | pm10_24h_co2 | ||
17 | rainratein | 84 | co2 | ||
18 | eventrainin | 85 | co2_24h | ||
19 | hourlyrainin | 86 | lightning_num | ||
20 | dailyrainin | 87 | lightning | ||
21 | weeklyrainin | 88 | lightning_time | ||
22 | monthlyrainin | 89,90,91,92 | leak_ch1 …., leak_ch4 | ||
23 | yearlyrainin | 93,94,95,96,97,98,99,100 | tf_ch1, …., tf_ch8 | ||
24 | totalrainin | 101 - 108 | leafwetness_ch1,…, leafwetness_ch8 | ||
25 | rrain_piezo | 109 - 112 | air_ch11),….air_ch4 | ||
26 | erain_piezo | 113 | console_batt | ||
27 | hrain_piezo | 114 | wh65batt | ||
28 | drain_piezo | 115 | wh80batt | ||
29 | wrain_piezo | 116 | wh26batt | ||
30 | mrain_piezo | 117 - 124 | batt1,….,batt8 | ||
31 | yrain_piezo | 125 - 132 | soilbatt1,…,soilbatt8 | ||
32 | ws90cap_volt | 133 - 136 | pm25batt1, …, pm25batt4 | ||
33 | ws90_ver | 137 | wh57batt |
1) air: lds01 height between sensor and surface; 2) thi: lds total height (user defined); 3) depth = thi - air (LDS: laser distance sensor)
as the sensor names show, the data is sent in imperial units –> endings in f [°F], in [inches], mph [miles per hour], CO2 concentration in ppm [parts per million], particulate matter in μg/m3, lightning time is the time stamp in seconds in EPOCH notation [seconds passed since 1.1.1980]
piezo stands for the haptic/piezo rain sensor [WS90], batt stands for the battery values - these are reported differently depending on sensor (see section battery status )
sensor_battery_status_values_etc
the real-world post of a GW2000 console with a WS90 and multiple other sensors to a custom server address could look like this:
PASSKEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&stationtype=GW2000A_V3.1.5.1&runtime=112824&heap=137368&dateutc=2024-09-11+17:33:09&tempinf=75.02&humidityin=54&baromrelin=29.994&baromabsin=28.978&tempf=53.24&humidity=76&winddir=252&windspeedmph=1.34&windgustmph=3.13&maxdailygust=17.00&solarradiation=3.39&uv=0&rainratein=0.000&eventrainin=0.240&hourlyrainin=0.000&dailyrainin=0.240&weeklyrainin=0.752&monthlyrainin=2.350&yearlyrainin=32.929&totalrainin=32.929&rrain_piezo=0.000&erain_piezo=0.114&hrain_piezo=0.000&drain_piezo=0.114&wrain_piezo=0.512&mrain_piezo=1.996&yrain_piezo=32.988&ws90cap_volt=5.4&ws90_ver=143&srain_piezo=1&temp1f=53.96&humidity1=78&temp2f=57.74&humidity2=70&temp3f=53.60&humidity3=79&temp4f=53.96&humidity4=92&temp5f=5.72&temp6f=57.74&humidity6=70&temp7f=43.88&humidity7=52&soilmoisture1=49&soilad1=245&soilmoisture2=46&soilad2=240&soilmoisture3=45&soilad3=247&soilmoisture4=79&soilad4=360&soilmoisture5=75&soilad5=353&soilmoisture6=55&soilad6=271&pm25_ch1=5.0&pm25_avg_24h_ch1=23.6&pm25_ch2=3.0&pm25_avg_24h_ch2=5.4&tf_co2=70.52&humi_co2=59&pm25_co2=2.0&pm25_24h_co2=25.4&pm10_co2=2.6&pm10_24h_co2=29.2&co2=653&co2_24h=675&lightning_num=0&lightning=37&lightning_time=1725579097&leak_ch2=0&tf_ch1=55.76&tf_ch2=36.32&leafwetness_ch1=40&air_ch3=13&thi_ch3=4000&depth_ch3=3987&wh25batt=0&batt1=0&batt2=0&batt3=0&batt4=0&batt5=0&batt6=0&batt7=0&soilbatt1=1.5&soilbatt2=1.4&soilbatt3=1.5&soilbatt4=1.6&soilbatt5=1.4&soilbatt6=1.4&pm25batt1=5&pm25batt2=5&wh57batt=3&leakbatt2=4&tf_batt1=1.36&tf_batt2=1.48&lcdbatt3=1.48&co2_batt=6&leaf_batt1=1.58&wh90batt=3.28&freq=868M&model=GW2000A&interval=8
your posting string might be much smaller. The console posts the values from all connected/registered sensors after having applied the sensor hierarchy (see there). Non present sensors will be omitted.
a handy way to know your custom server posting string (or to test if your console is posting properly) is to use the service at
http://ear.phantasoft.de
which is provided courtesy of user @olicat of wxforum.net
instructions are available when connecting to the site via webbrowser
the data to be entered to make the console post to http://ear.phantosoft.com:
protocol | Ecowitt |
---|---|
Server IP / Hostname | ear.phantasoft.de |
Path | /data/report/ |
Port | 80 |
Interval | 30 |
many weather applications are able to read the Ecowitt protocol:
application | driver, station name |
---|---|
CumulusMX | http(ecowitt), http(ambient)* |
HomeAssistant | Ecowitt integration |
Meteobridge | Ecowitt Custom Upload |
Meteotemplate | Ecowitt Plugin |
weewx | Interceptor |
*) the Ambient protocol differs from the Ecowitt protocol, mainly by the sensor names used
the free information broker software tool FOSHKplugin can also enrich the Ecowitt or WU protocol from Fine Offset consoles with derived values like Feels Like, Wind CHill, Heat Index, Dew Point etc.
often used weather services via Customized Server
Weather Service | protocol | host domain | path | port | interval |
---|---|---|---|---|---|
AWEKAS | WU | ws.awekas.at | /weatherstation/updateweatherstation.php?ID=[awekasid]&[awekaspassword] | 80 | 300 |
Windy | WU | stations.windy.com | /pws/update/[windyAPIkey]? | 80 | 300 |
PWSWeather | WU | pwsupdate.pwsweather.com | /api/v1/submitwx?ID=[PWS-ID]&PASSWORD=[PWS-Password]& | 80 | 300 |
PWSWeather (alternative) | WU | www.pwsweather.com | /pwsupdate/pwsupdate.php?ID=myID&PASSWORD=myPassword& | 80 | 300 |
Weather Underground | WU | rtupdate.wunderground.com | /weatherstation/updateweatherstation.php?ID=[WU-ID]&PASSWORD=[WU-Password]&action=updateraw& | 80 | 300 |
Ambient Weather Network (AWN) | AMB* | api.ambientweather.net | /endpoint? | 80 | 300 |
*) to post data to AWN you either need an Ambient console or an information broker software like FOSHKplugin to transform the WU or Ecowitt format into Ambient format (AMB).
when you are posting in WU format, only one set of rain data can be posted. If you have a traditional rain rauge (WH69/WH65 or WH40) and a piezo rain gauge (WS85/WS90) connected to your console, the setting “rainfall priority” in your console or in the rain totals of the WSV+ app or the WebUI determines, which data is sent as rain to the recipient.
the brackets “[ ]” are NOT supposed to be entered - they are just separators here for your ID and password to enter - characters like ? and & mentioned in the path MUST be entered
the customized MQTT posting
since firmware GW2000 3.1.9 and GW3000 1.0.2 a new protocol choice has been introduced by Ecowitt:
MQTT - all IoT enabled consoles will finally have this feature.
it can so far (January 2025) only be seen in the WebUI of the two gateways - the Ecowitt app needs to be on a version > 1.1.51 and logged into the local WLAN the console is registered in - WS View Plus still needs to be updated (> 2.0.53)
a 32 Byte field for accomodating a user selectable topic name is available the default topic name being the SSID of the inbuilt AP/hotspot of the console - e.g. GW3000A-WIFIxxxx.
we may need a short deep(er) dive into what MQTT is and how it can be used
Definition
MQTT (originally an initialism of MQ Telemetry Transport) is a lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth, such as in the Internet of Things (IoT). It must run over a transport protocol that provides ordered, lossless, bi-directional connections—typically, TCP/IP (Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP)).
it works like publishing an advertisement (information concerning a subject, e.g. I want to sell my car) in a newspaper section (topic, e.g. used car sales section) in a newpaper edition (message with specific topic sent to the MQTT broker). People interested in buying used cars can subscribe to that newspaper (subscribe to the topic with the MQTT broker). When the seller publishes the advertisement (send message with a topic, I am selling this and this car) in a newspaper edition (new message with topic used cars sales), the subscriber receives the message (gets the newspaper with the specific advertisement).
So it is (usually) not a direct machine-to-machine communication but a message handler (information broker) in between. (There is also direct client-to-client communication - e.g. MQTT Websocket Service)
A protocol is a structured definition of the communication from beginning to end and sending the communication content (payload) between start and end - like a phone call
you have to dial a number, the phone rings with the receiver of the call, the recipient picls up the call, the conversation (information exchange) takes place, the communication is ended.
the different steps have to take place is a special sequence and with special actions. The actions are represented by the so-called MQTT-packets - different ones for different purposes. And you follow an action sequence: you obviously do not talk before the connection is established - and you don't hang up before having started to calling/dialling procedure.
the most important step, represented by special MQTT packets, are listed below - the packet type and more information about it including a possible payload are defined in the starting byte of the message.
a typical MQTT message consists of three portions
- fixed header = control field (contains packet type, flags, length of remaining packet, mandatory, size: 1 byte)
- variable header (protocol name length, protocol name, protocol level [4 or 5]*, connection flag, keep alive time, optional, packet type dependent, size: 1 - 4 bytes) - 4 = MQTT version 3.1.1, 5 = version 5.0
- payload (message content, size: max 256 MB - (2 to 4 bytes))
typical packet types (message types)
MQTT packet type | function |
---|---|
CONNECT | establish/request the connection to the MQTT broker |
CONNACT | confirmation that the connection has been sucessfully established |
PUBLISH | sending your message with topic information and payload [content] |
SUBSCRIBE | register with the MQTT broker for a specific topic |
DISCONNECT | end the connection |
Then an (IoT enabled) Ecowitt console will post (publish) the custom server string information content (see above) to a MQTT server under the chosen topic (default hotspot name/SSID e.g. GW3000A-WIFIxxxx), and e.g. HomeAssistant can subscribe via it's MQTT integration to that topic and retrieve the published data.
It needs to be noticed that HA does not provide a MQTT server, which means that the console cannot directly post to HA but only via a separate MQTT server as man-in-the-middle - like a mail-sorting place. That also means that either a public or own, private MQTT server needs to be used or installed before this communication works (e.g. a mosqitto server on a RaspeberyPi, NAS or other server).
(Not only) For HomeAssistant FOSHKplugin provides a ready-made solution to transfer the “normal” customized data in Ecowitt protocol and then transform them into MQTT protocol also allowing to create all the entities relating to the sensor values which otherwise will have to be creted manually by creating a special YAML configuration file.
10d. the Customized Server feature of the Ambient consoles
while in principle the same logic applies as decribed with the Ecowitt consoles, (amongst other things) due to the different sensor naming and different number of supported sensors by Ambient consoles, there is also a different data communcation protocol - the Ambient protocol.
Ambient consoles post to AWN (Ambient Weather network) in Ambient protocol - and for the customized server option there are two protocols available: Wunderground and Ambient.
Ambient consoles do not post to WU directly with a preset option as Ecowitt consoles do. This option was available earlier but has been removed, probably because Ambient offer a data forwarding via their AWN. Therefore one either has to use the AWN Wunderground forward option or send directly via the customized server option. The configuration information can be found here: often used custom server targets
A table with the available sensors and their names in the custom server posting string and an example is shown below:
custom server string / console posting string to AWN (https://api.ambientweather.net/endpoint?) console: WH2682B-WIFIxxxx
PASSKEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&stationtype=WH2682B_V2.0.3&runtime=266607&heap=136804&dateutc=2024-09-29+13:41:02&tempinf=69.98&humidityin=53&baromrelin=30.327&baromabsin=29.311&tempf=54.86&humidity=61&winddir=21&windspeedmph=5.14&windgustmph=8.05&maxdailygust=16.55&solarradiation=123.44&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=4.276&yearlyrainin=34.870&totalrainin=34.870&rrain_piezo=0.000&erain_piezo=0.000&hrain_piezo=0.000&drain_piezo=0.000&wrain_piezo=0.000&mrain_piezo=3.925&yrain_piezo=34.996&srain_piezo=0&ws90cap_volt=5.4&ws90_ver=147&temp1f=55.58&humidity1=66&temp2f=59.90&humidity2=64&temp3f=55.58&humidity3=64&temp4f=55.94&humidity4=78&temp5f=0.14&temp6f=63.32&humidity6=64&temp7f=42.08&humidity7=44&soilhum1=45&soilad1=232&soilhum2=56&soilad2=279&soilhum4=79&soilad4=359&soilhum5=73&soilad5=344&soilhum6=56&soilad6=273&pm25=5.0&pm25_24h=6.6&pm25_in=3.0&pm25_in_24h=9.2&pm_in_temp_aqin=66.74&pm_in_humidity_aqin=56&pm25_in_aqin=1.5&pm25_in_24h_aqin=2.5&pm10_in_aqin=2.0&pm10_in_24h_aqin=3.1&co2_in_aqin=692&co2_in_24h_aqin=625&lightning_day=0&lightning_distance=37&lightning_time=1725579097&leak2=0&soiltemp1=48.20&soiltemp2=32.36&soiltemp3=52.34&leafwetness_ch1=11&battin=1&batt1=1&batt2=1&batt3=1&batt4=1&batt5=1&batt6=1&batt7=1&battsm1=1&battsm2=1&battsm4=1&battsm5=1&battsm6=1&batt_25=1&batt_25in=1&batt_lightning=3&batleak2=4&batt_tf1=1&batt_tf2=1&batt_tf3=1&batt_co2=1&leaf_batt1=1.46&battout=1&freq=868M&model=WH2682B&interval=8
sensor readings in red are not known to AWN and therefore not shown on AWN either
e.g. Soil Moisture AD values and WN34 sensors
Background: the string was posted by FOSHKplugin converting an Ecowitt protocol string into an Ambient protocol string
# | sensor name | ## | sensor name | ### | sensor name |
---|---|---|---|---|---|
01 | PASSKEY | 34,36,38,40,42,44,46,48 | tempf1,….,,tempf8 | 131 | srain_piezo |
02 | stationtype | 35,37,39,41,43,45,47,49 | humidity1,….,humidity8 | 132 | wh90batt |
03 | runtime | 50,52,54,56,58,60,62,64 | soilmoisture1,….., soilmoisture8 | 133 | freq |
04 | dateutc | 51,53,55,57,59,61,63,65 | soilad1,…., soilad8 | 134 | model |
05 | tempinf | 66,68,70,72 | pm25, pm25_in | 135 | interval |
06 | humidityin | 67,69 | pm25_avg_24h_ch1,…..,pm25_avg_24h_ch4 | 136 | |
07 | baromrelin | 70 | pm_in_temp_aqin | 137 | |
08 | baromabsin | 71 | pm_in_humidity_aqin | 138 | |
09 | tempf | 72 | pm1_in_aqin | ||
10 | humidity | 73 | pm1_in_24h_aqin | ||
11 | winddir | 74 | pm25_in_aqin | ||
12 | windspeedmph | 75 | pm25_24h_in_aqin | ||
13 | windgustmph | 86 | pm4_in_aqin | ||
14 | maxdailygust | 77 | pm4_24h_in_aqin | ||
15 | solarradiation | 78 | pm10_in_aqin | ||
16 | uv | 79 | pm10_24h_in_aqin | ||
17 | rainratein | 80 | co2_in_aqin | ||
18 | eventrainin | 81 | co2_24hin_aqin | ||
19 | hourlyrainin | 82 | lightning_day | ||
20 | dailyrainin | 83 | lightning_distance | ||
21 | weeklyrainin | 84 | lightning_time | ||
22 | monthlyrainin | 85,86,87,88 | leak_ch1 …., leak_ch4 | ||
23 | yearlyrainin | 89 - 96 | leafwetness_ch1,…, leafwetness_ch8 | ||
24 | totalrainin | 97 | battin | ||
25 | rrain_piezo | 98 - 105 | batt1,….,batt8 | ||
26 | erain_piezo | 106 - 113 | soilbatt1,…,soilbatt8 | ||
27 | hrain_piezo | 114 | bat25 | ||
28 | drain_piezo | 115 | bat25in | ||
29 | wrain_piezo | 116 | battout | ||
30 | mrain_piezo | 117 | batt_lightning | ||
31 | yrain_piezo | 118 - 121 | batleak1, …, batleak4 | ||
32 | ws90cap_volt | 122 | batt_CO2 | ||
33 | ws90_ver | 123-130 | leaf_batt1, …,leaf_batt8 |
10e. the ecowitt.net dashboard
when you have created an account at ecowitt.net, have your console registered there (device type: weather station) with its MAC address and have activated the posting to ecowitt.net in your console, you will see the Ecowitt Dashboard as shown below. How many sensors you see will depend on how many sensors are registered with your console.
The top portion consists of tiles which show the current readings and with some of them also the min and max readings of the day. You can move the tiles around by clicking on the caption, holding and moving. You can change the caption text by clicking on the default text. In the settings you can select which data is public (= can be seen by everybody registered at ecowitt.net) and you can share your dashboard view with people who are not registered at ecowitt.net. You can set alarms, choose the display units etc.
under the tile comes the graph and table section - there you can see the sensor history for each sensor. The default view is the current day, but you can also choose week, month or year as timeframe. You can switch between the graphic view and the table view.
The dashboard is updated every minute (unless you have chosen a different interval in your console) and every 5 minutes the average value of the past five minute posts is stored - and will be kept for 90 days. For more details on data resolution and retention times, see the respective point in the table of contents. retention times
If you have more than one console registered, you can select them in the top center portion.
the Ecowitt “Battery” tile explained
on the Ecowitt dashboard battery tile you find the battery status of all your sensors connected to the console (deie) which posts data this its dashboard. For possible battery values of the different sensors, see sensor battery status
in the tile the different arrays are shown with names rather than with their acroynym
for a breakdown see the table below
dashboard tile name | sensor name |
---|---|
Sensor Array | WH65/WS69/WN67 |
Wind Sensor | WS68 |
Sonic Array | WS80 |
Haptic 3-in-1 | WS85 |
Haptic array | WS90 |
Outdoor T&RH Sensor | WN32/WH32-EP |
T&RH&P Sensor | WH32 indoor/WH32B/WN32P |
——————————————————————————————————————————————————————————————
10f. the Ambient Weather Network (AWN) dashboard
the Ambient Weather Network (AWN) dashboard was at least in the beginning of its life based on the same software that is used by Fine Offset for the Ecowitt Weather Cloud or Ecowitt Weather Service as the ecowitt.net dashboard. Later on, at least on the user interface design level, they have somewhat drifted apart.
The AWN dashboard allows you to choose either a white or a dark background - or it can automatically toggle between a day and night viw when so configured in the settings.
While on ecowitt.net everything is shown on one page (tiles first, then either graph or table view) on AWN you can choose tabs for each representation. At the tile bottom there are quick links to the graphs. Also, each tile can be magnified (+) and then the period related min and max values are shown. Contrary to the ecowitt.net dashboard the tile position is fixed and tiles cannot be moved. Tile captions can simply be changed - by clicking on the caption name one can edit the text. With the (-) mini-button you can hide a tile and it will be moved to the end of the page.
example of an expanded outdoor temperature tile (or widget in Ambient speech):
There is also a weather forecast tile and a Min/Max tile by the name “Quick View”.
The battery tile is rather small-lipped and only shows one status for all (whereas on the ecowitt.net dashboard the battery for each sensor or array is shown in a scrollable battery tile).
The console posts, when activated, every minute, the dashboard page updates every 1-2 minutes, the posted data are accumulated, averaged and saved in five-minute intervals. Min/max values are shown for the day but not stored.
the rain event shown in the rain tile is different from the rain event shown on the consoles !
Every owner of an Ambient console or gateway can post their data to AWN after creating a user account and registering the console via its MAC address. The license fee is included in the purchase fee.
Also non-Ambient devices can post to AWN:
pre-requisite:
1. a seperately acquired license which will be bound to the MAC address of the device
2. the device has to post in Ambient protocol (which is different from the Ecowitt protocol).
Applications like FOSHKplugin can be used to convert Ecowitt protocol into Anbient protocol and post to AWN.
A local expandable weather map can be opened above the tiles and different observations can be chosen.
There is also an AWN app available which displays the browser dashboard adapted to a smartphone or tablet screen.
AWN comes in two versions:
1. Standard: free - data retention one year - basic map layers - 3-day hourly forecast
2. AWN+: ~ 6 USD/month, 60 USD/year - data retention 3 years - more map layers - 10-day hourly forecast - additional tiles
A table view of the data where data to be displayed can be filtered is available when clicking on the “charts” or “graph” icon on the “Charts & Graphs” page.
in table view (called “Chart”) one sees only the actual data and the min/max values of the day so far
by clicking on the (+) icon (only visible when you scroll horizontally ~50% of the width !!) the 5-minute data will be displayed.
The (+) icon then turns into an (x) icon which closes the 5-minute view.
Data can also be downloaded as a CSV file based on the display selection.
The console data can also be posted to Weather Underground (WU). Either via the AWN website or via the custom server feature of each Fine Offset manaufactured console. In Ambient branded consoles there is no preset WU posting feature as you find in the non-Ambient Fine Offset/Ecowitt consoles. You have to use the custom(ized) server feature.
how to post data from your AWN dashboard to Weather Underground
prerequisite: you have registered you weather station at www.wunderground.com and have received a Station ID and a Station Key (password) in your account data at WU
it can take up to 24 hours until your data become visible at your dashboard on the Wunderground Weather Website
——————————————————————————————————————————————————————————————
10g. Weather Services to send your PWS data to
- a. preset weather services
- Ambient consoles - AMB, WU (via AWN: WU and PWS)
- Ecowitt and clone consoles (Ecowitt, WU, WeatherCloud, WOW)
- data logger software (CumulusMX, Meteobridge, Weather Display, weewx)
- information broker software (FOSHKplugin)
- b. weather services to be reached with the Customized Service console feature
- c. weather services with other data formats (need individual customization)
under construction - to be completed
——————————————————————————————————————————————————————————————
11. data logging and information broker software and Ecowitt consoles
it may be advisable to first read the chapter on data flow 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 and WS6210 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 inerted) 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.
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 below.
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.
————————————————————————————————————————————————————————————————
PWT - Personal Weather Tablet (Android app)
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:
protocol | Ecowitt |
---|---|
Server IP / Hostname | IP-address-of-Android-tablet |
Path | /data/report/ |
Port | 8572 |
Interval* | 8 |
How to install PWT
download PWT from Google Play store (you will have to search with “PWT”)*- start PWT
- a setup wizard will be offered - press “continue”
- once set up the app should receive and display live data from your console
- you can also press “settings” and walk through the shown tabs on top from left to right
- 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
the CumulusMX Administration Dashboard
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.
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 4.
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 version is 3.2.5 build 3283 (03-Mar-2024)/4.1.1 build 4025 (19-Jun-2024). 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.
It has its own user community built and maintained WiKi at https://cumuluswiki.org/a/Software
—————————————————————————————————————————————————————————
how to connect Ecowitt consoles to CumulusMX (CMX)
how to connect Ecowitt consoles to CumulusMX (CMX)
As for Ecowitt (clone) consoles it can estabilsh the communication in three ways:
(1) via the local Ecowitt Gateway API | those consoles which have this API (see Compatibility Matrix under local network API/GW1000 API) |
(2) via the customized server functionality | this every Ecowitt (clone) console possesses (see Customize Server ) |
(3) via the Ecowitt cloud | needs APP key and API key from ecowitt.net user account (CMX station type “Ecowitt cloud“) |
selection to be made in CMX (Settings –> Station Settings –> General Settings)
interface | Cumulus MX station type |
---|---|
local Ecowitt Gateway API | (CMX station type “Ecowitt Local API) |
Ecowitt protocol | (CMX station type “HTTP(Ecowitt)” ) |
Ecowitt protocol | (CMX station type “Ecowitt cloud” ) |
Ambient protocol | (CMX station type “HTTP(Ambient)“ |
Wunderground protocol | (CMX station type “HTTP(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
protocol | Ecowitt |
---|---|
Server IP / Hostname | your-CMX-server-IP-address |
Path | /station/ecowitt |
Port | 8998 |
Interval | 8 |
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
the CMX file system
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).
We will describe the purpose and content of a few diretories, for further details look up the CMX Wiki (link above)
directory/folder | content |
---|---|
backup | CMX makes backups of its important files at midnight and ever time you retart CMX they are put into the “backup” directory as subdirectories named with the timestamp of the backup - the daily backups are in the subdirectory “daily” |
data | here the start-up info files .ini and the database files .txt are kept - today.ini is updated every time the observation data is saved to the database files (simple CSV files) MMMYYlog.txt and ExtraLogYYYYMM.txt, e.g. Mar24.txt (basic data) and ExtraLog202403.txt (Extra Sensor data) |
MXdiags | when the error logging is switched on (highly recommended ! –> Settings –> Program Settings –> Logging options [Debug logging, Data logging]), CMX creates a new log file at every restart YYYYMMXX-HHMMSS.txt e.g. 20240314-002300.txt which then contains all CMX activities and data transfers. When the file exceeds a size of 20 MB a new file will be created. see excerpt below |
webfiles | the files building the default website coming with CMX - if you want to use it, you have to copy (e.g. FTP) the content of this folder including the subfolders to your web host. Let's assume you created a directory “CumulusMX” in the webroot of your web host, then all has to be transferred there and you will be able to see the webpages by entering your-webhost-domain/CumulusMX in your web browser. You will still have to make CMX post the updated weather data regularly in the Settings –> Internet Settings |
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
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:
- create an API key in your personal ecowitt.net account (click on the avatar picture top right)
- create an APP key in your personal ecowitt.net account
- enter this information in CMX (Settings –> Station settings –> Ecowitt Cloud Access API)
- 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)
- save the changed settings
(Settings –> Station settings –> Ecowitt Cloud Access API)
there are now two scenarios:
- 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
- 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
before change | after change | |
---|---|---|
#Last updated: 03.03.2024 01:05:00 | —> | #Last updated: 03.12.2023 00:00:00 |
[General] | [General] | |
Date=03.03.2024 | —> | Date=03.12.2023 |
Timestamp=2024-03-05T01:05:00 | —> | Timestamp=2023-12-03T00:00:00 |
CurrentYear=2024 | —> | CurrentYear=2023 |
CurrentMonth=3 | —> | CurrentMonth=12 |
CurrentDay=3 | —> | CurrentDay=3 |
(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.
how to rename your Extra Sensors in CMX
how to rename your Extra Sensors in CMX
you have to edit the file strings.ini in the …/CumulusMX directory
[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
CMX Sensor name group | Ecowitt Sensor Name |
---|---|
[UserTempCaptions] | WN34 temperature |
[ExtraSensorCaptions] | not applicable |
[ExtraTempCaptions] | WN31, WN30, WN36 |
[ExtraHumCaptions] | WN31, WN36 |
[ExtraDPCaptions] | Dew point of WH31 sensors |
[SoilTempCaptions] | not applicable |
[SoilMoistureCaptions] | WH51, WH51D |
[LeafTempCaptions] | not applicable |
[LeafWetnessCaptions] | WN35 |
[AirQualityCaptions] | WH41, WH43 |
[CO2Captions] | WH45 (air quality only) |
——————————————————————————————————————————————————————————————–
running two instances of CMX on the same server
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 CumulusMX.exe (normally under Windows it would be enough just to enter "cumulusmx")
in the second console window you enter
C:> cd \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
——————————————————————————————————————————————————————————————–
introduced changes with CumulusMX v. 4
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
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
- 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 as an option
- To access use: http://<cmx_IP_address>:8998/ai2/index.html
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 * 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
- HTTP local API (applicable to all consoles with the local Ecowitt API except for the GW1000 and WH2650)
- TCP** 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) - HTTP Custom Server (a function to send data available by ALL Ecowitt consoles)
- Ecowitt.net cloud (retrieving data posted erlier by the console to the Ecowitt Weather Cloud, ALL consoles can do this)
*) imho “station connection type” would be the better term here
**) TCP is imho a misleading term here as http is also transported via tcp/ip (maybe BINARY would be less confusing)
the differentiation meant here is between sending a binary/hexadecimally coded non-standard request via a tcp connection or a request coded with the standard http protocol via a tcp connection.
tcp is the motorway/highway and http or other protocols are the different car models or types on that street
tcp is also a protocol but on a different network layer
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.
Meteobridge / Weatherbridge
overview
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 CO2 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.
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 three different drivers for modern Ecowitt (clone) stations:
- GW1000 (for consoles with the local Ecowitt network API)
- Ecowitt custom upload (for all consoles with the actual WiFi Firmware)
- 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
using the Ecowitt custom upload station with Meteobrige
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
protocoll | Ecowitt |
---|---|
hostname/IP address | the IP address of your Meteobridge e.g. 192.168.1.23 |
path | public/ecowittn.cgi |
port | 80 |
intervall | 8 seconds |
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.
rename or re-assign sensors in Meteobridge
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
observation | station # | sensor # | meaning [log.] |
---|---|---|---|
temperature | primary | 0 | outdoor temperature |
th | 0! | 0 | th0!0temp [th0temp] |
temperature | primary | 0 | indoor temperature |
thb | 0! | 0 | thb0!0temp [thb0temp] |
temperature | primary | 1-8 | extra temperature (WH31) |
th | 0! | 1 | th0!1temp [th1temp] |
th | 0! | 1 | th0!1temp [th1temp] |
th | 0! | … | th0!…temp [th…temp] |
th | 0! | 8 | th0!1temp [th1temp] |
……
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.
————————————————————————————————————————————————————————————————-
Meteobridge VM
the latest platform for the Meteobridge software is the installation in a virtual machine (VM)
for details see:
Meteobridge VM
————————————————————————————————————————————————————————————————-
weewx
Weewx
to be completed
introduction and overview
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 two Ecowitt related drivers are important:
- the Interceptor driver written by Matthew Wall
- the Ecowitt local gateway API driver (a.k.a. GW1000 driver) written by Gary Roderick
The Interceptor driver uses the data posted by Ecowitt consoles via the customized server functionality.
The Ecowitt local gateway API driver uses the application programming interface available with
the 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
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 Gateway API driver and background information see https://github.com/gjr80/weewx-gw1000/wiki
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.)
—————————————————————————————————————————————————————————
how does weewx work
how does weewx work
weewx has three main configuration files which can also be edited by the user:
weewx.conf | the central configuration file for station, driver, database, skins, labels etc. |
---|---|
skin.conf | instructions for the imagegenerator to produce single or combined historical pictures |
index.html.tmpl | the main script which creates the visible webpage (skin) |
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
where are the main weewx files located in the file system
the below table is for the Debian type of installation
element | symbolic name | file system location |
---|---|---|
WeeWX root directory | WEEWX_ROOT | /etc/weewx/ |
location of weewx.conf | WEEWX_ROOT | /etc/weewx/ |
Skins and templates | SKIN_ROOT | /etc/weewx/skins/ |
Seasons skin.conf | SKIN_ROOT/Seasons | /etc/weewx/skins/Seasons/ |
Seasons index.html.tmpl | SKIN_ROOT/Seasons | /etc/weewx/skins/Seasons/ |
User directory | USER_ROOT | /usr/share/weewx/ |
Examples | EXAMPLE_ROOT | examples/ |
Executables | BIN_ROOT | /usr/bin/ |
Extensions/drivers | —– | /usr/share/weewx/user/* |
SQLite databases | SQLITE_ROOT | /var/lib/weewx/** |
Web pages and images | HTML_ROOT | /var/www/html/weewx/ |
*) 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
——————————————————————————————————————————————————————————————————-
the local Ecowitt Gateway API driver field map (a.k.a. GW1000 API field map)
based on local Ecowitt driver version 0.6.0b6 - 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
with driver version 0.7.0 (still in development as a2) the backfill option from ecowitt.net as already implemented in CumulusMX will also be supported
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
WeeWX field name | Gateway device field name | Remarks |
---|---|---|
co2 | co2 | WH45/46 CO2 |
co2_24h_avg | co2_24h_avg | WH45 24 hour average CO2 |
dateTime | datetime | Epoch timestamp (seconds since 1.1.1970) |
daymaxwind | daymaxwind | Maximum wind speed today |
dayRain | t_rainday | Total traditional gauge rainfall today |
dewpoint | dewpoint | Dew point |
extraHumid1 | humid1 | WH31 channel 1 humidity |
extraHumid2 | humid2 | WH31 channel 2 humidity |
extraHumid3 | humid3 | WH31 channel 3 humidity |
extraHumid4 | humid4 | WH31 channel 4 humidity |
extraHumid5 | humid5 | WH31 channel 5 humidity |
extraHumid6 | humid6 | WH31 channel 6 humidity |
extraHumid7 | humid7 | WH31 channel 7 humidity |
extraHumid8 | humid8 | WH31 channel 8 humidity |
extraHumid17 | humid17 | WH45/WH46 humidity |
extraTemp1 | temp1 | WH31 channel 1 temperature |
extraTemp2 | temp2 | WH31 channel 2 temperature |
extraTemp3 | temp3 | WH31 channel 3 temperature |
extraTemp4 | temp4 | WH31 channel 4 temperature |
extraTemp5 | temp5 | WH31 channel 5 temperature |
extraTemp6 | temp6 | WH31 channel 6 temperature |
extraTemp7 | temp7 | WH31 channel 7 temperature |
extraTemp8 | temp8 | WH31 channel 8 temperature |
extraTemp9 | temp9 | WN34 channel 1 temperature |
extraTemp10 | temp10 | WN34 channel 2 temperature |
extraTemp11 | temp11 | WN34 channel 3 temperature |
extraTemp12 | temp12 | WN34 channel 4 temperature |
extraTemp13 | temp13 | WN34 channel 5 temperature |
extraTemp14 | temp14 | WN34 channel 6 temperature |
extraTemp15 | temp15 | WN34 channel 7 temperature |
extraTemp16 | temp16 | WN34 channel 8 temperature |
extraTemp17 | temp17 | WH45/WH46 temperature |
heap_free | heap_free | free heap memory |
heatindex | heatindex | heat index |
inHumidity | inhumid | inside humidity |
inTemp | intemp | inside temperature |
leafWet1 | leafwet1 | WN35 channel 1 |
leafWet2 | leafwet2 | WN35 channel 2 |
leafWet3 | leafwet3 | WN35 channel 3 |
leafWet4 | leafwet4 | WN35 channel 4 |
leafWet5 | leafwet5 | WN35 channel 5 |
leafWet6 | leafwet6 | WN35 channel 6 |
leafWet7 | leafwet7 | WN35 channel 7 |
leafWet8 | leafwet8 | WN35 channel 8 |
leak1 | leak1 | WH55 channel 1 |
leak2 | leak2 | WH55 channel 2 |
leak3 | leak3 | WH55 channel 3 |
leak4 | leak4 | WH55 channel 4 |
lightning_distance | lightningdist | distance to last lightning strike |
lightning_last_det_time | lightningdettime | Epoch timestamp of last lightning strike |
lightning_strike_count | lightning_strike_count | total lightning strike count this period |
lightningcount | lightningcount | cumulative lightning strike count |
luminosity | light | luminosity |
monthRain | t_rainmonth | total traditional gauge rainfall this month |
outHumidity | outhumid | outside humidity |
outTemp | outtemp | outside temperature |
p_dayRain | p_rainday | total piezo gauge rainfall today |
p_monthRain | p_rainmonth | total piezo gauge rainfall this month |
p_rain | p_rain | total piezo gauge rainfall this period |
p_rainRate | p_rainrate | piezo gauge rain rate |
p_stormRain | p_rainevent | total piezo gauge rainfall this rain event |
p_weekRain | p_rainweek | total piezo gauge rainfall this week |
p_yearRain | p_rainyear | total piezo gauge rainfall this year |
pm2_5 | pm251 | WH41/WH43 channel 1 PM2.5 |
pm2_52 | pm252 | WH41/WH43 channel 2 PM2.5 |
pm2_53 | pm253 | WH41/WH43 channel 3 PM2.5 |
pm2_54 | pm254 | WH41/WH43 channel 4 PM2.5 |
pm2_55 | pm255 | WH45/WH46 PM2.5 |
pm2_51_24h_avg | pm251_24h_avg | WH41/WH43 channel 1 24 hour average PM2.5 |
pm2_52_24h_avg | pm252_24h_avg | WH41/WH43 channel 2 24 hour average PM2.5 |
pm2_53_24h_avg | pm253_24h_avg | WH41/WH43 channel 3 24 hour average PM2.5 |
pm2_54_24h_avg | pm254_24h_avg | WH41/WH43 channel 4 24 hour average PM2.5 |
pm2_55_24h_avg | pm255_24h_avg | WH45/WH46 24 hour average PM2.5 |
pm10 | pm10 | WH46 PM10 |
pm10_24h_avg | pm10_24h_avg | WH46 24 hour average PM10 |
pm10_0 | pm10_0 | WH45 with driver 0.6.3 PM10 |
pm10_0_24h_avg | pm10_0_24h_avg | WH45 with driver 0.6.3 PM10 24 hour average |
pressure | absbarometer | absolute or station pressure |
rain | t_rain | total traditional gauge rainfall this period |
rainRate | t_rainrate | traditional gauge rain rate |
relbarometer | relbarometer | relative pressure |
soilMoist1 | soilmoist1 | WH51 channel 1 soil moisture |
soilMoist2 | soilmoist2 | WH51 channel 2 soil moisture |
soilMoist3 | soilmoist3 | WH51 channel 3 soil moisture |
soilMoist4 | soilmoist4 | WH51 channel 4 soil moisture |
soilMoist5 | soilmoist5 | WH51 channel 5 soil moisture |
soilMoist6 | soilmoist6 | WH51 channel 6 soil moisture |
soilMoist7 | soilmoist7 | WH51 channel 7 soil moisture |
soilMoist8 | soilmoist8 | WH51 channel 8 soil moisture |
soilMoist9 | soilmoist9 | WH51 channel 9 soil moisture. Note 2* |
soilMoist10 | soilmoist10 | WH51 channel 10 soil moisture. Note 2* |
soilMoist11 | soilmoist11 | WH51 channel 11 soil moisture. Note 2* |
soilMoist12 | soilmoist12 | WH51 channel 12 soil moisture. Note 2* |
soilMoist13 | soilmoist13 | WH51 channel 13 soil moisture. Note 2* |
soilMoist14 | soilmoist14 | WH51 channel 14 soil moisture. Note 2* |
soilMoist15 | soilmoist15 | WH51 channel 15 soil moisture. Note 2* |
soilMoist16 | soilmoist16 | WH51 channel 16 soil moisture. Note 2* |
soilTemp1 | soiltemp1 | Note 1* |
soilTemp2 | soiltemp2 | Note 1* |
soilTemp3 | soiltemp3 | Note 1* |
soilTemp4 | soiltemp4 | Note 1* |
soilTemp5 | soiltemp5 | Note 1* |
soilTemp6 | soiltemp6 | Note 1* |
soilTemp7 | soiltemp7 | Note 1* |
soilTemp8 | soiltemp8 | Note 1* |
soilTemp9 | soiltemp9 | Note 1* |
soilTemp10 | soiltemp10 | Note 1* |
soilTemp11 | soiltemp11 | Note 1* |
soilTemp12 | soiltemp12 | Note 1* |
soilTemp13 | soiltemp13 | Note 1* |
soilTemp14 | soiltemp14 | Note 1* |
soilTemp15 | soiltemp15 | Note 1* |
soilTemp16 | soiltemp16 | Note 1* |
stormRain | t_rainevent | total traditional gauge rainfall this rain event |
totalRain | t_raintotals | total traditional gauge rainfall recorded |
UV | uvi | UV index |
uvradiation | uv | UV radiation |
weekRain | t_rainweek | total traditional gauge rainfall this week |
wh24_batt | wh24_batt | WH24 battery level |
wh24_sig | wh24_sig | WH24 signal level |
wh25_batt | wh25_batt | WH25 battery level |
wh25_sig | wh25_sig | WH25 signal level |
wh26_batt | wh26_batt | WH26 battery level |
wh26_sig | wh26_sig | WH26 signal level |
wh31_ch1_batt | wh31_ch1_batt | WH31 channel 1 battery level |
wh31_ch1_sig | wh31_ch1_sig | WH31 channel 1 signal level |
wh31_ch2_batt | wh31_ch2_batt | WH31 channel 2 battery level |
wh31_ch2_sig | wh31_ch2_sig | WH31 channel 2 signal level |
wh31_ch3_batt | wh31_ch3_batt | WH31 channel 3 battery level |
wh31_ch3_sig | wh31_ch3_sig | WH31 channel 3 signal level |
wh31_ch4_batt | wh31_ch4_batt | WH31 channel 4 battery level |
wh31_ch4_sig | wh31_ch4_sig | WH31 channel 4 signal level |
wh31_ch5_batt | wh31_ch5_batt | WH31 channel 5 battery level |
wh31_ch5_sig | wh31_ch5_sig | WH31 channel 5 signal level |
wh31_ch6_batt | wh31_ch6_batt | WH31 channel 6 battery level |
wh31_ch6_sig | wh31_ch6_sig | WH31 channel 6 signal level |
wh31_ch7_batt | wh31_ch7_batt | WH31 channel 7 battery level |
wh31_ch7_sig | wh31_ch7_sig | WH31 channel 7 signal level |
wh31_ch8_batt | wh31_ch8_batt | WH31 channel 8 battery level |
wh31_ch8_sig | wh31_ch8_sig | WH31 channel 9 signal level |
wh32_batt | wh32_batt | WH32 battery level |
wh32_sig | wh32_sig | WH32 signal level |
wh40_batt | wh40_batt | WH40 battery level |
wh40_sig | wh40_sig | WH40 signal level |
wh41_ch1_batt | wh41_ch1_batt | WH41/WH43 channel 1 battery level |
wh41_ch1_sig | wh41_ch1_sig | WH41/WH43 channel 1 signal level |
wh41_ch2_batt | wh41_ch2_batt | WH41/WH43 channel 2 battery level |
wh41_ch2_sig | wh41_ch2_sig | WH41/WH43 channel 2 signal level |
wh41_ch3_batt | wh41_ch3_batt | WH41/WH43 channel 3 battery level |
wh41_ch3_sig | wh41_ch3_sig | WH41/WH43 channel 3 signal level |
wh41_ch4_batt | wh41_ch4_batt | WH41/WH43 channel 4 battery level |
wh41_ch4_sig | wh41_ch4_sig | WH41/WH43 channel 4 signal level |
wh45_batt | wh45_batt | WH45/WH46 battery level |
wh45_sig | wh45_sig | WH45/WH46 signal level |
wh51_ch1_batt | wh51_ch1_batt | WH51 channel 1 battery level |
wh51_ch1_sig | wh51_ch1_sig | WH51 channel 1 signal level |
wh51_ch2_batt | wh51_ch2_batt | WH51 channel 2 battery level |
wh51_ch2_sig | wh51_ch2_sig | WH51 channel 2 signal level |
wh51_ch3_batt | wh51_ch3_batt | WH51 channel 3 battery level |
wh51_ch3_sig | wh51_ch3_sig | WH51 channel 3 signal level |
wh51_ch4_batt | wh51_ch4_batt | WH51 channel 4 battery level |
wh51_ch4_sig | wh51_ch4_sig | WH51 channel 4 signal level |
wh51_ch5_batt | wh51_ch5_batt | WH51 channel 5 battery level |
wh51_ch5_sig | wh51_ch5_sig | WH51 channel 5 signal level |
wh51_ch6_batt | wh51_ch6_batt | WH51 channel 6 battery level |
wh51_ch6_sig | wh51_ch6_sig | WH51 channel 6 signal level |
wh51_ch7_batt | wh51_ch7_batt | WH51 channel 7 battery level |
wh51_ch7_sig | wh51_ch7_sig | WH51 channel 7 signal level |
wh51_ch8_batt | wh51_ch8_batt | WH51 channel 8 battery level |
wh51_ch8_sig | wh51_ch8_sig | WH51 channel 8 signal level |
wh51_ch9_batt | wh51_ch9_batt | WH51 channel 9 battery level. Note 2* |
wh51_ch9_sig | wh51_ch9_sig | WH51 channel 9 signal level. Note 2* |
wh51_ch10_batt | wh51_ch10_batt | WH51 channel 10 battery level. Note 2* |
wh51_ch10_sig | wh51_ch10_sig | WH51 channel 10 signal level. Note 2* |
wh51_ch11_batt | wh51_ch11_batt | WH51 channel 11 battery level. Note 2* |
wh51_ch11_sig | wh51_ch11_sig | WH51 channel 11 signal level. Note 2* |
wh51_ch12_batt | wh51_ch12_batt | WH51 channel 12 battery level. Note 2* |
wh51_ch12_sig | wh51_ch12_sig | WH51 channel 12 signal level. Note 2* |
wh51_ch13_batt | wh51_ch13_batt | WH51 channel 13 battery level. Note 2* |
wh51_ch13_sig | wh51_ch13_sig | WH51 channel 13 signal level. Note 2* |
wh51_ch14_batt | wh51_ch14_batt | WH51 channel 14 battery level. Note 2* |
wh51_ch14_sig | wh51_ch14_sig | WH51 channel 14 signal level. Note 2* |
wh51_ch15_batt | wh51_ch15_batt | WH51 channel 15 battery level. Note 2* |
wh51_ch15_sig | wh51_ch15_sig | WH51 channel 15 signal level. Note 2* |
wh51_ch16_batt | wh51_ch16_batt | WH51 channel 16 battery level. Note 2* |
wh51_ch16_sig | wh51_ch16_sig | WH51 channel 16 signal level. Note 2* |
wh55_ch1_batt | wh55_ch1_batt | WH55 channel 1 battery level |
wh55_ch1_sig | wh55_ch1_sig | WH55 channel 1 signal level |
wh55_ch2_batt | wh55_ch2_batt | WH55 channel 2 battery level |
wh55_ch2_sig | wh55_ch2_sig | WH55 channel 2 signal level |
wh55_ch3_batt | wh55_ch3_batt | WH55 channel 3 battery level |
wh55_ch3_sig | wh55_ch3_sig | WH55 channel 3 signal level |
wh55_ch4_batt | wh55_ch4_batt | WH55 channel 4 battery level |
wh55_ch4_sig | wh55_ch4_sig | WH55 channel 4 signal level |
wh57_batt | wh57_batt | WH57 battery level |
wh57_sig | wh57_sig | WH57 signal level |
wh65_batt | wh65_batt | WH65 battery level |
wh65_sig | wh65_sig | WH65 signal level |
wh68_batt | wh68_batt | WH68 battery voltage |
wh68_sig | wh68_sig | WH68 signal level |
windchill | windchill | wind chill |
windDir | winddir | wind direction |
windGust | gustspeed | wind gust speed |
windSpeed | windspeed | wind speed |
wn34_ch1_batt | wn34_ch1_batt | WN34 channel 1 battery level |
wn34_ch1_sig | wn34_ch1_sig | WN34 channel 1 signal level |
wn34_ch2_batt | wn34_ch2_batt | WN34 channel 2 battery level |
wn34_ch2_sig | wn34_ch2_sig | WN34 channel 2 signal level |
wn34_ch3_batt | wn34_ch3_batt | WN34 channel 3 battery level |
wn34_ch3_sig | wn34_ch3_sig | WN34 channel 3 signal level |
wn34_ch4_batt | wn34_ch4_batt | WN34 channel 4 battery level |
wn34_ch4_sig | wn34_ch4_sig | WN34 channel 4 signal level |
wn34_ch5_batt | wn34_ch5_batt | WN34 channel 5 battery level |
wn34_ch5_sig | wn34_ch5_sig | WN34 channel 5 signal level |
wn34_ch6_batt | wn34_ch6_batt | WN34 channel 6 battery level |
wn34_ch6_sig | wn34_ch6_sig | WN34 channel 6 signal level |
wn34_ch7_batt | wn34_ch7_batt | WN34 channel 7 battery level |
wn34_ch7_sig | wn34_ch7_sig | WN34 channel 7 signal level |
wn34_ch8_batt | wn34_ch8_batt | WN34 channel 8 battery level |
wn34_ch8_sig | wn34_ch8_sig | WN34 channel 9 signal level |
wn35_ch1_batt | wn35_ch1_batt | WN35 channel 1 battery level |
wn35_ch1_sig | wn35_ch1_sig | WN35 channel 1 signal level |
wn35_ch2_batt | wn35_ch2_batt | WN35 channel 2 battery level |
wn35_ch2_sig | wn35_ch2_sig | WN35 channel 2 signal level |
wn35_ch3_batt | wn35_ch3_batt | WN35 channel 3 battery level |
wn35_ch3_sig | wn35_ch3_sig | WN35 channel 3 signal level |
wn35_ch4_batt | wn35_ch4_batt | WN35 channel 4 battery level |
wn35_ch4_sig | wn35_ch4_sig | WN35 channel 4 signal level |
wn35_ch5_batt | wn35_ch5_batt | WN35 channel 5 battery level |
wn35_ch5_sig | wn35_ch5_sig | WN35 channel 5 signal level |
wn35_ch6_batt | wn35_ch6_batt | WN35 channel 6 battery level |
wn35_ch6_sig | wn35_ch6_sig | WN35 channel 6 signal level |
wn35_ch7_batt | wn35_ch7_batt | WN35 channel 7 battery level |
wn35_ch7_sig | wn35_ch7_sig | WN35 channel 7 signal level |
wn35_ch8_batt | wn35_ch8_batt | WN35 channel 8 battery level |
wn35_ch8_sig | wn35_ch8_sig | WN35 channel 8 signal level |
ws80_batt | ws80_batt | WS80 battery voltage |
ws80_sig | ws80_sig | WS80 signal level |
ws90_batt | ws90_batt | WS90 battery voltage |
ws90_sig | ws90_sig | WS90 signal level |
yearRain | t_rainyear | total traditional gauge rainfall this year |
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)
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:
[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'
—————————————————————————————————————————————————————————
what do you see on your local or internet webpage
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:
- the current data table top left (left portion of the page) - red circle
- the celestial data table (if activated in skin.conf) - top of blue circle
- the min/max data of the chosen time frame for each observation (sensor data) - blue circle
- 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/m2 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 # ......... # *********************
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
- 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/m2.
- That is, one obtains 683.002 lux per W/m2 (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/m2 ⇒ 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/m2 = 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:
protocol | Ecowitt |
---|---|
Server IP / Hostname | your-weewx-server-IP-address |
Path | / |
Port | 8000 |
Interval | 8 |
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.
weewx observation | definition |
---|---|
pressure | The Station Pressure (SP), which is the raw, absolute pressure measured by the station. This is the true barometric pressure for the station. |
barometer | The Sea Level Pressure (SLP) obtained by correcting the Station Pressure for altitude and local temperature. This is the pressure reading most commonly used by meteorologist to track weather systems at the surface, and this is the pressure that is uploaded to weather services by WeeWX. It is the station pressure reduced to mean sea level using local altitude and local temperature. |
altimeter | The Altimeter Setting (AS) obtained by correcting the Station Pressure for altitude. This is the pressure reading most commonly heard in weather reports. It is not the true barometric pressure of a station, but rather the station pressure “reduced”* to mean sea level using altitude and an assumed temperature average. |
*) 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[T1 + T2 + …+ Tx] / x for x = 144 or 144 5 minute intervals = 12 hours,
but just
(Tnow - T12-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
for more air pressure related information see Barometer
————————————————————————————————————————————————————————————————-
how to show the Seasons skin on your web host
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
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 latetest version
sudo apt-get update sudo apt-get upgrade
3. install a webserver program - nginx or apache2 - it is nneded 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
- create the subdirectory for the webserver
- allow the webserver to access this subdirectory
- create a subdirectory for the report files
- mount a temperory file system into that link
- make the mount permanent
- 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)
how to install weewx on a Windows 10/11 computer (WSL)
to be completed
—————————————————————————————————————————————————————————
how to install weewx 5.0 in a Python VENV environment
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 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
—————————————————————————————————————————————————————————————
the proposed wview_ecowitt database schema
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 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
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
running multiple instances of weewx to combine observations from different weather stations in one skin/webpage
to be completed
Weather Display
Weather Display (current version 10.37S151 Windows) 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
- local Ecowitt API (GW1000, telnet …)
- Customized Server option
- data supply from the Ecowitt cloud at ecowitt.net
- 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
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.
Sensors and Hubs (consoles/gateway) connect to HA via so-called integrations
Ecowitt consoles use the so-called “Ecowitt intgration” per console where the console posts to the HA using the customized server functionality Custom Server of each LAN/WLAN enabled console. The console will be connected via a so-called webhook which will be provided by HA during installation of 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 integrations. 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.
Per default HA uses port 8123 to communicate with an Ecowitt console.
HA instructions on How to use the HA Ecowitt integration
Once HA receives data from an Ecowitt console, it will display a list of all sent sensors. The sensors will be named using a console/firmware combination as a start and then the sensor function.
Attention: in the current Ecowitt integration (March 2024) the daily acumulated rain is wrongly named rain_rate.
Now you can choose available dashboard elements (tiles) of different types to depict your sensors: sensors, statistics, tables, instruments etc.
the current version of the Ecowitt 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:
post string variable | sensor | meaning | remark |
---|---|---|---|
'heap' | console RAM size | free heap RAM | shows potential memory leaks |
'co2in' | WN1821, WS3910 | inbuilt CO2 sensor | current CO2 concentration |
'co2in_24h' | WN1821, WS3910 | inbuilt CO2 sensor | 24h average CO2 concentration |
'soilad1' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad2' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad3' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad4' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad5' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad6' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad7' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'soilad8' | WH51, WH51L | soil moisture AD | analog-digital calibrated percentage |
'console_batt' | WS2320, WS2910, WS3800, WS3900 | console battery [Volts] | console backup battery status |
'WS85_batt'* | WS85 | WS85 battery [Volts] | WS85 backup battery status |
'WS85_capacitor'* | WS85 | WS85 capacitor [Volts] | WS85 capacitor charging status |
*) 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
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. 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.
Note that for all MQTT implementations a MQTT server is needed - it is not provided by HomeAssistant but must either be separately installed or an 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
there is an HA IoT integration offered at GitHub
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
————————————————————————————————————————————————————————————————-
openHAB (open Home Automation Bus)
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
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
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
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 etc.
- add information to the data received from the console like sunshine hours, 10 min average wind speed etc.
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 Windows [Win10/11]) and others).
The below picture shows examples of its features and the weather services and/or data logger programs involved
the data to be entered to make your Ecowitt (clone) console post to FOSHKplugin:
protocol | Ecowitt |
---|---|
Server IP / Hostname | IP-address-of-FOSHKplugin-server |
Path | /data/report/ |
Port | 8080 |
Interval* | 8 |
*) or an interval of your choice: 8-600 seconds
(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 …)
Features: (November 2024)
- 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)
- 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 can be found under the below link: FOSHKplugin
————————————————————————————————————————————————————————————————-
RTL 433 SDR
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
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))
————————————————————————————————————————————————————————————————-
12. sensor (array) transmission timings / reporting intervals
13. sensor hierarchy
per console only one of the outdoor temp/hum, traditional rain, piezo rain, wind and solar sensors will be shown
if more than one of these types are registered to the console, the below hierarchy is applied by the console
(this applies to the HP25x0, HP350x, GW1x00, GW2000, WN19x0, WH2650 and WS3800/WS39x0 consoles)
priority shown in the table is from right (highest) to left (lowest) - see also pictures further down
(for details on all different types of temperature sensors see temperature sensors)
outdoor temp/hum: | WH65/WS69 ←- WS80 ←- WS90 ←- WH32(-EP) |
indoor temp/hum/air pressure: | GW1100/GW2000 [since firmware 2.3.1/3.1.1] inbuilt sensors ←- WH32B (WH32 indoor) |
rain: | WH65/69 ←- WH40 |
piezo rain: | WS90 ←- WS85 |
wind: | WH65/WS69 ←- WS68 ←- WS80 ←- WS90 ←- WS85 |
solar: | WH65/WS69 ←- WS68 ←- WS80 ←- WS90 |
The GW1000/WH2650 (firmware >= 1.7.4), GW1100, GW2000 (firmware >= 2.1.4), WN19x0/WN18x0 (firmware >0 1.2.0) and WS3800/39×0 consoles can have a traditional (WH65/WS69, WH40) and a haptic/piezo rain gauge (WS90) simultaniously connected and synoptically shown in either the WS View app, the Ecowitt app* or in their WebUI. The HP25x0 consoles (firmware >= 1.8.0) can so far only show either or (traditional or piezo) with both connected.
*) or in the Ecowitt cloud dashboard
Outdoor temperature display priority
Wind and Solar display priority (WS85 wind only)
Rainfall display priority
Air Pressure display priority
From February 2025 on a new WS69 model will be released which also contains a pressure sensor. The WS90 already has an inbuilt pressure sensor, but its reading are so far only used by a WN90LP via the RS485 interface.
Therefore indoor temperature/humidity and pressure will be decoupled for such arrays and a new pressure sensor hierarchy established.
Background is the WS6210 console/gateway which in combination with sensor arrays other than a WS90 would not get pressure readings (unless you add a sheltered WN32P/WH32B as the location of the WS6210 may be far away from some indoor facility.).
————————————————————————————————————————————————————————————————-
14. APIs (application programming interfaces)
Historically, the Ecowitt Gateway API is an evolutionary product which started from the need of connecting, configuring, calibrating a displayless console and also displaying its data in realtime when cloud service was not yet well established at Fine Offset / Ecowitt.
The first device to be handled that way was the network (LAN) connected displayless WH2600 (Observer IP) console (“gateway”) moving away from a USB connection to the becoming more and more popular network option.
Experience had been gained on the display console side when retrieving data from the USB connected WH1080 and the first WLAN connected successor model, the WH2300/WS2320. There interface software was built (WeatherSmart with USB and then WeatherSmart for WiFi/WeatherSmartIP) which retrieved in the data via the network across an API, that the WS2320E consoles nowadays (December 2024) still have and still can be used together with a MS Access local database.
The communication between the those days WS View app took place via a TCP/IP based protocol (“telnet”), the local Ecowitt gateway API with hexadecimally coded commands and replies.
The next quantum leap came with the GW1000 and the now WLAN-enabled successor of the WH2600, the WH2650.
Finally, with the GW2000 and the Ambient Observer IP2 (the WH2685) and now also its successor, the GW3000 (and the Ambient Weather Network Hub 2.0/Observer IP3), the interfaces are LAN plus WLAN and the communication protocol has been moved from HEX codes to http based JSON data exchange implemented in the WS View Plus app, which still uses the legacy telnet protocol for handling the legacy GW1000 and WH2650 gateways.
14.a the Ecowitt Gateway API (application programming interface) a.k.a. GW1000 API
(a.k.a. telnet protocol)
the Ecowitt Gateway API (EW-GW API) is an interface which allows applications to retrieve data from an Ecowitt console/gateway which supports this API.
There are quite a few well-known data logger programs which have drivers to query the local Ecowitt API (telnet and http). Some are called drivers, others “stations” etc. and this API itself has been given different names by their developers (CumulusMX: Ecowitt local API, weewx: local Ecowitt API or GW1000, Meteobridge: GW1000, Weather Display: GW1000). This often adds to the confusion of new users.
The name “GW1000” refers to the first Ecowitt console which came with this API. Meanwhile the GW1000 has reached its end-of-life and is no longer produced but has successor models.
Currently (November 2024) the following consoles have the local EW-GW API:
displayless consoles/gateways (for pictures see Gateways)
- GW1000 (no longer produced)
- WH2650 WiFi (WH2600 successor gateway with WiFi - sold under different names by various resellers e.g. Froggit, Steinberg Systems, Waldbeck, … mainly in Europe)
- GW1100 (GW1000 successor model)
- GW1200 (GW1100 successor model, IoT enabled*)
- GW2000 (recent Ecowitt gateway, sold together with the Ecowitt WS90 outdoor array as GW2001 station, also available as single gateway/console, IoT enabled)
- GW3000 (latest Ecowitt gateway, GW2000 successor, IoT enabled, prospective release date December 2024)
- WS6210 (combined 3G-4G/WiFi console)
- WH2685 (mainly sold as Ambient ObserverIP 2.0 module - Ambient restrictions apply, even though a GW1100/GW2000 deprived of their indoor T/H sensors would act as a WH2685 without the Ambient restrictions)
consoles with display (for pictures see Display Consoles)
- WN19x0 and WN182x consoles (lightweight console)
- the WS3800/WS3900/WS3910 consoles
- the Ambient WS-1965 console
Note:
newer sensors like the WH54/LDS01 are no longer supported by the telnet API - instead the http local API (see link) has to be used. The http local API, however, does not work work with the older GW1000 and WH2650 consoles.
*) IoT enabled means that these consoles can manage the Ecowitt IoT devices (so far, November 2024, the WittSwitch AC1100 and the WittFlow WFC01)
(there is one more console which has a similar API, the WS2320E console. The WeatherSmart for WiFi or WeatherSmartIP software for Windows PCs retrieves data from a WS230E (clone) console, displays it in the software user interface and stores/archives the data in a Microsoft Access database. Custom software could also retrieve data from this console when the API description is known - independent of the server OS. The WS2320E has only a limited not expandable number of sensors, while the EW-GW API supports all recently available Ecowitt and reseller clone console sensors including Ambient.)
The API serves various purposes:
1. request device information
(device type/name, firmware version, RF reception frequency, free heap storage, temperature compensation, rain gauge priority)
2. retrieve and add/change posting to weather networks
(Ecowitt, Weather Underground [WU], WeatherCloud, WOW and a freely customized server address/domain, path, port and posting interval)
3. retrieve and add/change sensor calibration offsets or gain factors
4. register or disable sensors
5. retrieve information about registered sensors and their battery charge status
6. retrieve information of console/gateway runtime since last reboot
7. retrieve sensor readings (observations) on request
8. initiate a reboot of the console/gateway
the API description document by Ecowitt (Ecowitt naming: tcp/telnet)
The API is documented and released for public use by Ecowitt - latest version is 1.6.9.
gw1000_gw1100_telnet_v1.6.9.pdf
Ecowitt haven't updated their link on their website yet (February 2024) - they provide only a link to version 1.6.4
https://osswww.ecowitt.net/uploads/20220407/WN1900%20GW1000,1100%20WH2680,2650%20telenet%20v1.6.4.pdf
The documentation may not be easily readable by non-adepts without a certain level of software programming skills. Therefore we will explain its main functionality in the text below with examples.
Ecowitt provide an app (WS View Plus) which in its latest release can do all the above listed activities (1. - 7.) with all recent sensors/sensor arrays. The development of the legacy WS View app (without “Plus”) has been discontinued and it can no longer retrieve data from or configure all sensors - especially the WS90.
The app - or a custom developed program with an integrated network socket - can communicate with the respective consoles via the API using TCP protocol via port 45000 by sending defined commands and reading the related response from the console through its API.
(CumulusMX, Meteobridge, Weather Display and weewx have drivers or inbuilt software portions which can inquire the Ecowitt Gateway API and receive and process the API response)
For the data retrieval there are mainly two commands which would trigger a console response regarding current preprocessed weather sensor observation data:
1. CMD_GW1000_LIVEDATA
2. CMD_READ_RAIN
(this command was introduced to cover the data from the haptic/piezo rain sensor built into the WS90 sensor array [“Wittboy”])
(battery/signal data for all sensors/sensor arrays can be read via the command CMD_READ_SENSOR_ID_NEW)
The CMD_GW1000_LIVEDATA command sent as a hexadecimal (HEX) byte sequence to port 45000 of the gateway (IP address) triggers a variable length console/API response which contains the actual, current data of all sensors connected/registered with that console. The variable length is defined by the number and type of sensors connected to the console.
Below the decoded byte sequence of the retrieval request and of the API response: The general data exchange format is: Fixed header, CMD, SIZE, DATA1, DATA2, … , DATAn, CHECKSUM Fixed header: 2 bytes, header is fixed as 0xffff CMD: 1 byte, Command SIZE: 1 byte, packet size,counted from CMD till CHECKSUM DATA: n bytes, payloads,variable length CHECKSUM: 1 byte, CHECKSUM=CMD+SIZE+DATA1+DATA2+…+DATAn
CMD_GW1000_LIVEDATA 0xFF 0xFF 0x27 0x05 0xnn (FFFF = header, 27= Command, 05 = size, nn = CheckSum)
API response:0xFF 0xFF 0x27 0x00 0x9A 0x01 (FFFF = header, 27= Command, 0096 = payload size, payload, checksum [HEX 9A = DECIMAL 154])
[payload(s) means the observation related data sent by the console including administrative data, e.g. sensor name codes,
or, from the logistics terminology, where the word comes from:
Header + Command + content size + checksum is the Container, the payload is the content of the container and its packing list]
the payload data has the following structure: a marker or identifier of the sensor and the related data (the length of the data portion is defined in the API description) e.g. 0x01: Indoor Temperature; related data: multiples of 1/10 of the Indoor temperature in centigrades hexadecimally coded in two bytes
below a real-life API response from a GW1100 gateway - the list of connected sensor is shown under the response and the decoding description
(a software program for decoding the API response must identify the observation (marker, identifier) and the related data following the marker.)
this has been done manually below for a real-world API response:
(the API response comes as a data stream/string - it has been broken down into 2-byte protions in HEX notion for better reading)
┌───────────────────────────────────────┐
0xFF | 0xFF | 0x27 | 0x00 | 0x9A | 0x01 | 0x00 | 0xC8 |
0x06 | 0x39 | 0x08 | 0x26 | 0xE0 | 0x09 | 0x28 | 0x03 |
0x02 | 0x00 | 0x44 | 0x07 | 0x59 | 0x0A | 0x00 | 0x77 |
0x0B | 0x00 | 0x00 | 0x0C | 0x00 | 0x00 | 0x15 | 0x00 |
0x00 | 0x00 | 0x00 | 0x16 | 0x00 | 0x00 | 0x17 | 0x00 |
0x2A | 0x00 | 0x78 | 0x4D | 0x00 | 0xAF | 0x51 | 0x00 |
0x82 | 0x4E | 0x00 | 0x7D | 0x2C | 0x41 | 0x2E | 0x40 |
0x30 | 0x3E | 0x32 | 0x2B | 0x1A | 0x00 | 0x40 | 0x22 |
0x4C | 0x1B | 0x00 | 0x5A | 0x23 | 0x52 | 0x1C | 0x00 |
0x43 | 0x24 | 0x58 | 0x1D | 0x00 | 0x5B | 0x25 | 0x4F |
0x1E | 0xFF | 0x54 | 0x1F | 0x00 | 0x57 | 0x27 | 0x45 |
0x20 | 0x00 | 0x39 | 0x28 | 0x4B | 0x59 | 0x00 | 0x62 |
0x00 | 0x00 | 0x00 | 0x00 | 0x61 | 0x63 | 0x22 | 0x26 |
0x5E | 0x60 | 0x11 | 0x19 | 0x00 | 0x0C | 0x0E | 0x00 |
0x00 | 0x10 | 0x00 | 0x00 | 0x11 | 0x00 | 0x02 | 0x12 |
0x00 | 0x00 | 0x01 | 0xDB | 0x13 | 0x00 | 0x00 | 0x1A |
0x23 | 0x0D | 0x00 | 0x00 | 0x63 | 0x00 | 0x3C | 0x70 |
0x00 | 0xD3 | 0x34 | 0x00 | 0x61 | 0x00 | 0x9D | 0x00 |
0x55 | 0x00 | 0x96 | 0x02 | 0xB1 | 0x02 | 0xFF | 0x06 |
0x72 | 0x52 | 0x88 |
header: FF, FF, CMD, length from CMD to end including checksum - here 154 bytes (HEX 9A)
marker: | size | observation [unit] | Hex value from API |
---|---|---|---|
[bytes] | |||
0x01: | 2 | inTemp [1/10 °C] | 00C8 = 20.0 °C |
0x06: | 1 | inHum [%] | 39 = 57% |
0x08: | 2 | absPress [1/10 hPa] | 26E0 = 995.2 hPa |
0x09: | 2 | relPress [1/10 hPa] | 2803 = 1024.3 hPa |
0x02: | 2 | outTemp [1/10 °C] | 0044 = 6.8 °C |
0x07: | 1 | outHum [%] | 59 = 89% |
0x0A: | 2 | WindDir [°] | 0077 = 119° |
0x0B: | 2 | WindSpeed [m/s] | 0000 = 0 m/s |
0x0C: | 2 | windGust [m/s] | 0000 = 0 m/s |
0x15: | 4 | Solar [lux] | 00000000 = 0 Lux |
0x16: | 2 | SolRad [W/m2] | 0000 = 0 W/m2 |
0x17: | 1 | UVI [-] | 00 = 0 |
0x2A: | 2 | PM2.5 Ch1 [µg/m3] | 0078 = 12.0 µg/m3 |
0x2C: | 1 | soilMoist1 [%] | 41 = 65% |
0x2E: | 1 | soilMoist2 [%] | 40 = 64% |
0x30: | 1 | soilMoist3 [%] | 3E = 62% |
0x32: | 1 | soilMoist4 [%] | 2B = 43% |
0x34: | 1 | soilMoist5 [%] | (not present) |
0x36: | 1 | soilMoist6 [%] | (not present) |
0x38: | 1 | soilMoist7 [%] | (not present) |
0x3A: | 1 | soilMoist8 [%] | (not present) |
0x4D: | 2 | PM2.5 24h ch1 avg [µg/m3] | 00AF = 17.5 µg/m3 |
0x4E: | 2 | PM2.5 24h ch2 avg [µg/m3] | 0082 = 12.4 µg/m3 |
0x4F: | 2 | PM2.5 24h ch3 avg [µg/m3] | (not present) |
0x50: | 2 | PM2.5 24h ch4 avg [µg/m3] | (not present) |
0x51: | 2 | PM2.5 ch2 [µg/m3] | 00AF = 17.5 µg/m3 |
0x52: | 2 | PM2.5 ch3 [µg/m3] | (not present) |
0x53: | 2 | PM2.5 ch4 [µg/m3] | (not present) |
0x1A: | 2 | extraTemp1 [1/10 °C] | 0040 = 6.4°C |
0x22: | 1 | extraHum1 [%] | 4C = 76% |
0x1B: | 2 | extraTemp2 [1/10 °C] | 005A = 9.0°C |
0x23: | 1 | extraHum2 [%] | 52 = 82% |
0x1C: | 2 | extraTemp3 [1/10 °C] | 0043 = 6.7°C |
0x24: | 1 | extraHum3 [%] | 58 = 88% |
0x1D: | 2 | extraTemp4 [1/10 °C] | 005B = 9.1°C |
0x25: | 1 | extraHum4 [%] | 4F = 79% |
0x1E: | 2 | extraTemp5 [1/10 °C] | FF54 ** = -17.1°C |
0x26: | 1 | extraHum5 [%] | not present, WN30 |
0x1F: | 2 | extraTemp6 [1/10 °C] | 0057 = 9.3°C |
0x27: | 1 | extraHum6 [%] | 45 = 68% |
0x20: | 2 | extraTemp7 [1/10 °C] | 0039 = 6.3°C |
0x28: | 1 | extraHum7 [%] | 4B = 75% |
0x21: | 2 | extraTemp8 [1/10 °C] | not present |
0x29: | 1 | extraHum8 [%] | not present |
0x58: | 1 | Leak Ch1 [-] | not present |
0x59: | 1 | Leak Ch2 [-] | 0 = OK |
0x5A: | 1 | Leak Ch3 [-] | not present |
0x5B: | 1 | Leak Ch4 [-] | not present |
0x60: | 1 | lightning distance (last strike) [km] | 11 = 17 km |
0x61: | 4 | lightning time stamp (last strike) | 6322 265E = EPOCH 1663182430 *** |
0x62: | 4 | lightning day count [-] | 00000000 = 0 |
0x19: | 2 | day max wind [m/s] | 000C = 12 m/s = 43.2 km/h |
0x0E: | 2 | rain rate [mm/h] | 0 mm/h |
0x10: | 2 | rain day [mm] | 0 mm |
0x11: | 2 | rain week [mm] | 0.2 mm |
0x12: | 4 | rain month [mm] | 1DB =47.5 mm |
0x13: | 4 | rain year [mm] | 1A23 = 669.1 mm |
0x0D: | 4 | rain event [mm] | 0 mm |
0x63: | 2 | WN34L Ch1 [°C] | 003C = 6.0 °C |
0x64: | 2 | WN34 [1/10 °C] | Ch2 (not present |
0x65: | 2 | WN34 [1/10 °C] | Ch3 (not present |
0x66: | 2 | WN34 [1/10 °C] | Ch4 (not present |
0x67: | 2 | WN34 [1/10 °C] | Ch5 (not present |
0x68: | 2 | WN34 [1/10 °C] | Ch6 (not present |
0x69: | 2 | WN34 [1/10 °C] | Ch7 (not present |
0x6A: | 2 | WN34 [1/10 °C] | Ch8 (not present |
0x70: | 2 | WH45-temp [°C] | 00D3 = 211 = 21.1°C |
” | 1 | WH45-hum [%] | 34 = 52% |
“ | 2 | PM10 | 61 = 9.7 µg/m3 |
” | 2 | PM10-24 | 9D = 15.7 µg/m3 |
“ | 2 | PM2.5 | 55 = 8.5 µg/m3 |
” | 2 | PM2.5-24 | 96 = 15.0 µg/m3 |
“ | 2 | CO2 [ppm] | 02B1 = 689 ppm |
” | 2 | CO2-24 [ppm] | 02FF = 767 ppm |
“ | 1 | CO2-battery [-] | 6 = on DC |
0x72: | 1 | Leaf Wetness Ch1 [%] | 52 = 82% |
0x73: | 1 | WN35 Ch2 [%] | (not present) |
0x74: | 1 | WN35 Ch3 [%] | (not present) |
0x75: | 1 | WN35 Ch4 [%] | (not present) |
0x76: | 1 | WN35 Ch5 [%] | (not present) |
0x77: | 1 | WN35 Ch6 [%] | (not present) |
0x78: | 1 | WN35 Ch7 [%] | (not present) |
0x79: | 1 | WN35 Ch8 [%] | (not present) |
0x6C: | 4 | heap free* [bytes] | (not applicable → firmware |
last byte: | 1 | Checksum |
*) (in GW1100/GW2000/WS3800/WS39x0 firmware >= 2.3.1/3.1.1/1.2.4)
**) (FFFF-FF54=AB=171; FF = '-')
***) (= 14 September 2022 19:07:10)
inside this API response there are contained
- a WH32 as outdoor temperature and humidity
- the GW1100 indoor T/H and absolute and relative pressure
- the wind speed, maxGust daily, wind direction
- solar radiation and UVI
- 4 WH51 soil moisture sensors (channels 1-4)
- 7 WH31 extra T/H sensors (channels 1-7)
- 1 WN34L user defined temperature (channel 1)
- 1 WN35 leaf wetness sensor (channel 1)
- 1 WH55 waster leakage sensor (channel 2)
- 1 WH57 with daily lightning count, EPOCH time stamp
(seconds passed since 01-Jan-1970) of last lightning occurrence and distance of last lightning
- 1 WH40 with all (traditionally measured) rain data from the interface
- 1 WS90 with piezo rain data (piezo rain data to be retrieved separately with the CMD_READ_RAIN command)
- 1 WH45 with PM2.5, PM10, CO2 data (actual and 24h) plus WH45 temp/hum
- 2 WH41 PM2.5 sensors (channel 1 and 2)
in case of a WH46 sensor being registered not the marker 0x70 is provided but 0x6B
(this marker is until now undocumented by Ecowitt although existing)
0x6B: | 2 | WH45-temp [°C] | 1/10 °C – (e.g. 222 ~ 22.2 °C) |
” | 1 | WH45-hum [%] | |
“ | 2 | PM10 [µg/m3] | 1/10 µg/m3 |
” | 2 | PM10-24 [µg/m3] | 1/10 µg/m3 |
“ | 2 | PM2.5 [µg/m3] | 1/10 µg/m3 |
” | 2 | PM2.5-24 [µg/m3] | 1/10 µg/m3 |
“ | 2 | CO2 [ppm] | |
” | 2 | CO2-24 [ppm] | |
“ | 2 | PM1 [µg/m3] | 1/10 µg/m3 |
” | 2 | PM1-24 [µg/m3] | 1/10 µg/m3 |
“ | 2 | PM4 [µg/m3] | 1/10 µg/m3 |
” | 2 | PM4-24 [µg/m3] | 1/10 µg/m3 |
“ | 1 | CO2-battery [-] | valid values see sensor batteries |
it may appear at first glance that the marker sequence is not really ascending and sort of chaotic - there is some inbuilt logic - but in order to decode one has to take the indoor sensors first and then the outdoor sensors.
The first markers 0x01, 0x06, 0x08 and 0x09 are the indoor temperature, indoor humidity, absolute air pressure and relative air pressure.
Then come the outdoor sensors 0x02 in ascending sequence (with a few exceptions ](*,): for an extra temperature there is a related extra humidity which starts counting after the 8th extra Temperature sensor; also the PM2.5 WH41 sensors are somewhat out of sequence - that's because of a historically grown API). The decoding software has to know this sequence for proper decoding. Also for the WH45/WH46* values the byte sequence, size and allocation needs to be known. A WH51 soil moisture sensor has always a corresponding WN34 sensor for its “neighbour/successor”) - and the API allows for 16 soil moisture and 16 soil temperature (and 8 user defined) sensors, but the console firmware (so far) only allows for 8 WH51 soil moisture and 8 user defined sensors (WN34). At the end comes the max daily wind gust and the traditional rain data.
As theoretically all possible sensors could be connected to the console, all have to be checked for presence and if present for their observation data.
Therefore writing software for doing this decoding is quite a challenging and more complex job.
*) WH45 marker 0x70, WH46 marker 0x6B
With the CMD_READ_RAIN command all rain data of connected rain gauges (maximum one traditional [WH40 or WS69] and one piezo [WS90] rain gauge) can be retrieved
CMD_READ_RAIN has the command code 0x57
a typical (real-life) API response is:
header: FF, FF, CMD, length from CMD to end including checksum - here 86 bytes (HEX 56)
┌───────────────────────────────────────┐
0xFF | 0xFF | 0x57 | 0x00 | 0x56 | 0x01 | ||
0x0E | 0x00 | 0x06 | 0x10 | 0x00 | 0x00 | 0x00 | 0x03 |
0x11 | 0x00 | 0x00 | 0x00 | 0x03 | 0x12 | 0x00 | 0x00 |
0x04 | 0x8C | 0x13 | 0x00 | 0x00 | 0x1C | 0xC8 | 0x0D |
0x00 | 0x03 | 0x0F | 0x00 | 0x66 | 0x80 | 0x00 | 0x12 |
0x83 | 0x00 | 0x00 | 0x00 | 0x05 | 0x84 | 0x00 | 0x00 |
0x00 | 0x05 | 0x85 | 0x00 | 0x00 | 0x04 | 0xCB | 0x86 |
0x00 | 0x00 | 0x1D | 0x07 | 0x81 | 0x00 | 0x05 | 0x87 |
0x4C | 0xA5 | 0x00 | 0xA0 | 0x00 | 0xA0 | 0x00 | 0xA0 |
0x00 | 0xB4 | 0x00 | 0x64 | 0x00 | 0x64 | 0x00 | 0x64 |
0x00 | 0xB4 | 0x00 | 0x64 | 0x88 | 0x00 | 0x00 | 0x00 |
0x7A | 0x02 | 0xE5 |
the response contain the traditional rain gauge data (WH40, WS69) first; identifiers 0x0D - 0x14, (if registered to the console !)
marker: | size (bytes) | observation | data/values |
---|---|---|---|
0x0D: | 2 | rain event [1/10 mm] | 0.3 mm |
0x0E: | 2 | rain rate [1/10 mm/h] | 0.6 mm/h |
0x0F: | 2 | rain gain [1/100] | 66 = 1.02 |
0x10: | 2 | daily rain [1/10 mm] | 0.3 mm |
0x11: | 2 | weekly rain [1/10 mm] | 0.3 mm |
0x12: | 4 | monthly rain [1/10 mm] | 048C = 116.4 mm |
0x13: | 4 | yearly rain [1/10 mm] | 1CC8 = 736.8 mm |
0x14: | 4 | total rain [1/10 mm] | (more than one calendar year) |
as a side remark - the traditional rain readings above are the same as retrieved by the CMD_GET_GW1000_LIVEDATA
then come the piezo rain data from the WS90; identifiers 0x80 - 0x88, if a WS90 or a WS85 is registered to the console
marker: | size (bytes) | observation | data/values |
---|---|---|---|
0x80: | 2 | piezo rain rate [1/10 mm/h] | 12 = 1.8 mm/h |
0x81: | 2 | piezo rain event [1/10 mm] | 5 = 0.5 mm |
0x82: | 2 | reserved - not used | |
0x83: | 4 | piezo daily rain [1/10 mm] | 5 = 0.5 mm |
0x84: | 4 | piezo weekly rain [1/10 mm] | 5 = 0.5 mm |
0x85: | 4 | piezo monthly rain [1/10 mm] | 4CB = 122.7 mm |
0x86: | 4 |