Table of Contents
WiKi
(update status: 01-Oct-2024 - what's new ? see WIKI changelog)
Fine Offset/Ecowitt weather stations,
their clones* and pertaining sensors
(* Ambient, DNT, 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
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)
visitor and traffic statistics
interim visitor numbers - 30-Sep-2024
going-live date: 14-Mar-2024
(for a better [bigger] view open picture in a new browser tab - or click twice on the picture)
first 10,000 visitor number reached 13-Jul-2024
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 | 12516 | 12264 | 221 | 197 | 50065 | 49057 | 885 | 787 | 12.8 GB |
——————————————————————————————————————————————-
Daily Access Statistics for 2024-10 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Day | Hits | Media | Pages | Visitors | Traffic | |||||
01 | 10847 | 21.67% | 10609 | 21.63% | 205 | 23.16% | 275 | 34.94% | 2.8 GB | 21.98% |
02 | 12636 | 25.24% | 12409 | 25.30% | 195 | 22.03% | 122 | 15.50% | 2.8 GB | 21.70% |
03 | 14339 | 28.64% | 14020 | 28.58% | 287 | 32.43% | 194 | 24.65% | 3.9 GB | 30.23% |
04 | 12243 | 24.45% | 12019 | 24.50% | 198 | 22.37% | 196 | 24.90% | 3.3 GB | 26.09% |
——————————————————————————————————————————————-
Overview and introduction
(update status: 01-Oct-2024 - what's new ? see WIKI changelog)
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
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.
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.
*) this process is also called “pairing” (see console->router pairing process)
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 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)
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 - 2 m / ~3.3 - 6.6 feet above ground
- wind 10 - 15 m / ~33 - 49 feet above ground
in an obstacle-free environment.
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 (June 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 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 ←–not a real model number: *) HP2551 console + WS68 5-in-1 sensor array + indoor T&H&P 3-in-1 sensor (WH32B) + WH32 outdoor temperature sensor + WH40 rain gauge)
[user customized by adding components to the console]
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 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 + 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 (June 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, the 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 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 some of actual weather stations sold as packages (models, kits) by Froggit (June 2024):
———————————————————————————————————————————————————————————-
Ambient stations
Ambient LLC, Chandler, Arizona is a USA based company (, part of the Nielsen-Kellerman Company, Boothwyn, PA) which sells 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 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-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 (….)
(* 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 Anbient AQIN (air quality 7-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
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, WS38012 | 1 no solar data displayed, 2 no lightning 3 no air quality, 4 CO2 yes, PM no |
2 | all | GWxy00, WN19x0, WN182x live data w/ WS View Plus; others 1-minute data with Ecowitt app |
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. |
the consoles WS3800 and WS39x0 can be combined with ALL sensors
- 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 | 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), WN1910 2), WS3801 | GW1200 yes, GW2000 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
T/RH: temperature/relative humidity
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 |
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 | — | — | — | HP3001 | — | — | — |
WN182x | WN1820 WN1821 | — | — | — | — | 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 | — | — | — | — | — | — |
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 | dnt000005 | WH31 / WH32Q | — | — | — |
WH31-EP | WH31-EP / WN37xS | — | — | — | — | — | — | — | — |
WH32/WN32 | WH32/WN32 | (WH32E)* | DP40 | — | — | — | — | — | — |
WH32-EP | WH32-EP / WN39xS | — | — | — | — | — | — | — | — |
WH32B/WN32P | WH32B/WN32P | — | 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 | WH46 | — | — | — | — | — | — | — | — |
WH48 | — | AQIN 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
————————————————————————————————————————————————————————————————-
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 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: all 16 sensors usable for IoT smart plans
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
- 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
actual Ecowitt console models (August 2024)
WS6210 WLAN + 3G/4G ———————————————————GW3000
———————————————————————————————————————————————————–(not yet released)
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 )
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
————————————————————————————————————————————————————————————————-
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, is only in prototyping stage (15-Jul-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.
it will also be wall mountable.
As per the latest news (September 2024) it will come with a detachable coax-type external 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.)
——————————————————————————————————————————————————————————————
WH2600 - Ambient ObserverIP 1.0 (legacy)
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 2.0 new edition
Since about May/June 2024 Ambient offers the new design Weather Hub 2.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.
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.
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 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:
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
————————————————————————————————————————————————————————————————-
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)
Unfortunately, this console/station does not support all current 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.
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.
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.
In the meantime (March 2024) Ecowitt have indicated to offer the separate T&HP sensor option also for the HP2560 console with a future device firmware upgrade. With device firmware 1.9.5 the hardware intervention is no longer necessary and a seperate 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.
———————————————————————————————————————————————-
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
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.
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.
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. This often has to do not only 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 .
However, this only works with an HP2550 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).
Froggit: HP1000SE Pro
Froggit is now (January 2023) shipping 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)
The HP2560C is called HP2000 at Froggit and is available since January 2023
Froggit: HP2000
———————————————————————————————————————————————————————————-
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
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-5000 console on device firmware 1.9.6
comparative table of sensorIDs across resellers
Ecowitt (+ unmodified clones) | Ambient | GARNI |
---|---|---|
HP2550/HP2560 | WS-2000/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 | WS90 | 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
———————————————————————————————————————————————————————————-
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.
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
————————————————————————————————————————————————————————————————-
WN1820/WN1821
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.
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).
————————————————————————————————————————————————————————————————-
WS3800 and WS3900/WS3910
The WS3800/3900/3910 consoles with a relatively large LCD screen (diagonal 7.5 inches/19 cm) are available with a blue and white (WS3800) 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
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.
Also the configuration can be done via the SET button)
more details see WS3800 manual
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/46 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/4/1 values from a connected WH45/WH46 can be displayed in the bottom left CO2 display tile..
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.
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.
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 actaul 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)
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.
————————————————————————————————————————————————————————————————-
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
————————————————————————————————————————————————————————————————-
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
Ambient: WS-2902A,B,C,D-array, WS-2000/4000/5000-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)
———————————————————————————————————————————————————————————-
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
———————————————————————————————————————————————————————————-
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.
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 |
piezo 2 | >= 4 mm/h < 10 mm/h | 0.70 | 0.70 | ||
piezo 3 | >= 10 mm/h < 30 mm/h | 0.92 | 0.70 | ||
piezo 4 | >= 30 mm/h < 60 mm/h | 1.00 | 1.00 | ||
piezo 5 | >= 60 mm/h | 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
———————————————————————————————————————————————————————————————–
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/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.
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.
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
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, 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 plans (as of July 2023) to 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. At present, only the use of the built-in sensors is possible with these consoles (with normal means), whereby the console location is not always the optimum measuring location for indoor T/RH/P. With the HP2560/GW1100/GW2000, the sensor cables can be disconnected/soldered, but this also means opening the housing etc., which is not reasonable for every user.
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).
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.
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.
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 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.
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.
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. 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.
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 conole of the same radio freqeuncy is of couse also possible.
reseller product name: (WH45) - Froggit DP250, GARNI G083QC, Ambient AQUIN
———————————————————————————————————————————————————————————-
WH48 (new Ambient AQIN)
The WH48 is not yet published by Ambient so far (September 2024). It will replace the existing AQIN sensor (WH45 clone) and will come in a new housing. The Ambient consoles (WS-2000/4000/5000; AWN Weathr Hub [IP3] and ObserverIP2 [IP2]) will be able to register either one AQIN (old, WH45) or one AQIN (new, WH48). Ecowitt consoles won't be able to process the WH48 transmissions.
———————————————————————————————————————————————————————————-
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.
———————————————————————————————————————————————————————————-
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
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).
before you start the pairing process, switch off your mobile network in the smartphone or tablet
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.
We recommend to make the gateway IP address static - this you can do in the network configuration of the gateway.
————————————————————————————————————————————————————————————————-
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 !
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 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.
console firmware (device, WiFi - latest versions)
(last updated: 26-Sep-2024) - 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.6 | 02-May-2024 | 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.5 | dd-MMM-2024 | 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 |
HP2560: | 1.9.6 | 02-May-2024 | device firmware upgrade w/ EasyWeatherPro/AMBWeatherPro OTA | user-v1.9.6.zip |
1.9.7 | 11-Jul-2024 | device firmware upgrade w/ EasyWeatherPro/AMBWeatherPro OTA | user_v1.9.7.zip | |
1.9.8 | 13-Aug-2024 | device firmware upgrade w/ EasyWeatherPro/AMBWeatherPro OTA | user_v1.9.8.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 |
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.4 | 11-Jul-2024 | |
GW1200: | 1.3.2 | 05-Jul-2024 | |
GW2000: | 3.1.6 | 26-Sep-2024 | WS View Plus >= 2.0.50 needed |
GW3000: | 1.0.0 | 17-Jul-2024 | pre-release |
WS6006: | 1.1.35 | 11-Aug-2024 | PC software 1.7.1 |
WS6210: | 1.0.4 | 17-Sep-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.2.4 | 15-Jan-2024 | |
WN1980: | 1.3.2 | 26-Jul-2024 | |
WN182x: | 1.3.2 | 26-Jul-2024 | |
WS3800: | 1.3.0 | 30-Apr-2024 | |
WS39x0: | 1.3.0 | 30-Apr-2024 | |
WS-1965: | t.b.d. | xx-xx-202x | Ambient WS-1965 ~ Ecowitt WN1920 |
name | latest version | |
---|---|---|
WS View Plus | 2.0.51 | 21-Sep-2024 |
Ecowitt | 1.1.40 | 09-Sep-2024 |
outdoor arrays
name | latest version | |
---|---|---|
WS80 | 1.2.9 | 23-Sep-2024 |
WS90 | 1.4.7 | 26-Sep-2024 |
WS85 | 1.0.9 | 27-Sep-2024 |
———————————————————————————————————————————————————————————————–
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
So far it's the WS80 6-in-1 ultrasonic outdoor sensor array for which firmware updates are available, depending on the hardware revision
new firmware V.1.2.4 from 17-Jan-2023
- Optimize low/no wind speed detection algorithm
https://osswww.ecowitt.net/uploads/20230201/WS80_V1.2.4_Upgrade.zip
new firmware V.1.2.5 from 05-Apr-2023
- reduce/fix the problem of wind speed and direction remaining unchanged after rain
https://osswww.ecowitt.net/uploads/20230404/WS80_V1.2.5_Upgrade.zip
New WS80 firmware 1.2.8 Upgrade available (15-Apr-2024) WS80 1.2.8 firmware
Changelog:
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
New WS80 firmware 1.2.9 Upgrade available (23-Sep-2024) WS80 firmware 1.2.9 with toolkit for Windows
Changelog:
- 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
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 !)
Recently (April 2022) a firmware update V.1.1.7 for the WS90 ultrasonic 7-in-1 outdoor array was released.
it's supposed to provide a rain detection pattern improvement and thereby improve rain measurement accuracy.
A Windows PC/laptop is needed for the upgrade (Win7 - Win11)
A new firmware update V.1.1.9 is available (May 2022): (improvement of wind readings) download from https://www.ecowitt.com/shop/goodsDetail/249#
New WS90 Firmware V1.2.3 Upgrade available (14-Jul-2022)
https://osswww.ecowitt.net/uploads/20220713/WS90%20Firmware%20V1.2.3%20Upgrade.zip
improvements:
- Increased sensitivity for mist and drizzle rain detection.
- sensitivity for high rain rate adjusted to provide better lineararity.
New WS90 firmware V.1.2.5 Upgrade available (13-Aug-2022)
https://osswww.ecowitt.net/uploads/20220810/WS90_V1.2.5%20Firmware%20&%20Toolkit.zip
improvements:
- 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.
New WS90 firmware V.1.2.6 Upgrade available (21-Sep-2022)
https://osswww.ecowitt.net/uploads/20220921/WS90_V1.2.6%20Firmware%20&%20Toolkit.zip
useful for V.1.2.5 users where the sensor reacted too sensitive to mist or dew - otherwise no need for installation
New WS90 firmware V.1.3.0 Upgrade available (18-Jan-2023)
- Optimize low/no wind speed detection algorithm
https://osswww.ecowitt.net/uploads/20230201/WS90_V1.3.0%20Firmware%20&%20Tookit.zip
New WS90 firmware V.1.3.2 Upgrade available (29-Mar-2023)
https://osswww.ecowitt.net/uploads/20230329/WS90_Firmware%20&%20Tookit.zip
- 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
New WS90 firmware V.1.3.3 Upgrade available (17-Apr-2023)
https://osswww.ecowitt.net/uploads/20230417/WS90_Firmware%20&%20Tookit%20(1).zip
- Optimize rain detection algorithm
New WS90 firmware V.1.3.8 Upgrade available (25-Oct-2023)
https://osswww.ecowitt.net/uploads/20231025/WS90_Firmware%20&%20Tookit.zip
- 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
New WS90 firmware 1.4.3 Upgrade available (15-Apr-2024) WS90 1.4.3 firmware
Changelog:
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
New WS90 firmware 1.4.6 Upgrade available (23-Sep-2024) WS90 1.4.6 firmware with Windows toolkit
New WS90 firmware 1.4.7 Upgrade available (26-Sep-2024) WS90 1.4.7 firmware with Windows toolkit
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
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
New firmware 1.0.8 (01-Jul-2024) - improved readings at low wind speeds
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 |
Changelog (1.0.9):
- Optimize the ultrasonic sensor for wind speed measurement
- Optimize the wind speed algorithm to enhance accuracy
- Optimize rainfall measurement
————————————————————————————————————————————————————————————————-
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 WS6210 firmware
V. 1.0.4 - 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.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.2
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
------------------------- 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. 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.1.6 versions
V. 3.1.6 - Optimized WS85 and WS90 rain detection algorithm. - Fixed a memory leak issue. V. 3.1.5 - Supports 16 channels for WH51 soil moisture sensors. - Support WS85 and WS90 rain start detection. - Adjust the upload time interval. V. 3.1.4 - Optimizes RF reception performance V. 3.1.3 - Support WS85 sensor. - Support local web pages (WebUI) to control IOT sub-devices (manual only). V. 3.1.2 - Fixes ae 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 - Fixed bug where some devices could not upload ecowitt. - alternative WH32B (WH32 indoor) can be selected instead of inbuilt sensors. V. 3.1.0 - 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 - 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 - 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 - Optimized MQTT data upload - Optimized the sub-device offline problem V.3.0.4/3.0.5/3.0.6 - 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 - 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 - 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.4 versions
V. 2.3.4 - 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/WN1920 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 WN1980 firmware V.1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.2.3, 1.2.7 thru 1.3.2 versions
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.2 versions
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.35
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.6 versions
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
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)
————————————————————————————————————————————————————————————————-
8. 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.
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.
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.
Alternative elaborations by an “air pressure adept” can be found here:
Barometer
————————————————————————————————————————————————————————————————-
9. sensor battery status, values etc.
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) 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 (21-Sep-2024) is 2.0.51.* It supports all consoles and sensors of the Ecowitt ecosystem with the exception of the IoT devices (so far WFC01 and AC1100, March 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 are handled via the Ecowitt app.
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 need to be entered into a list of WU station which then can be displayed. No password is needed here.
The device list of WSV+ 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.
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 repeating the pairing process. Only consoles that have been paired again in the Ecowitt dashboard section of WSV+ can be displayed. What is shown are the one minute data the console posts to ecowitt.net.
you basically get the same display as from the Ecowitt app - without configuration options (e.g. IoT subdevices)
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) are queried via the http protocol. The htttp 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 app
Ecowitt app
latest version: 1.1.40 (09-Sep-2024)
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)
two protocols can be chosen: Ecowitt or Wunderground 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 (status: September 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 | srain_piezo |
02 | stationtype | 35,37,39,41,43,45,47,49 | humidity1,….,humidity8 | 139 - 146 | tf_batt1, …, tf_batt8 |
03 | runtime | 50,52,54,56,58,60,62,64 | soilmoisture1,….., soilmoisture8 | 147 | co2_batt |
04 | dateutc | 51,53,55,57,59,61,63,65 | soilad1,…., soilad8 | 148 - 155 | leaf_batt1, …, leaf_batt8 |
05 | tempinf | 66,68,70,72 | pm25_ch1, …., pm25_ch4 | 156 | wh90batt |
06 | humidityin | 67,69,71,73 | pm25_avg_24h_ch1,…..,pm25_avg_24h_ch4 | 157 | freq |
07 | baromrelin | 74 | tf_co2 | 158 | model |
08 | baromabsin | 75 | humi_co2 | 159 | interval |
09 | tempf | 76 | pm1_co2 | ||
10 | humidity | 77 | pm1_24h_co2 | ||
11 | winddir | 78 | pm25_co2 | ||
12 | windspeedmph | 79 | pm25_24h_co2 | ||
13 | windgustmph | 80 | pm4_co2 | ||
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 | console_batt | ||
26 | erain_piezo | 110 | wh65batt | ||
27 | hrain_piezo | 111 | wh80batt | ||
28 | drain_piezo | 112 | wh26batt | ||
29 | wrain_piezo | 113 -120 | batt1,….,batt8 | ||
30 | mrain_piezo | 121 - 128 | soilbatt1,…,soilbatt8 | ||
31 | yrain_piezo | 129,130,131,132 | pm25batt1, …, pm25batt4 | ||
32 | ws90cap_volt | 133 | wh57batt | ||
33 | ws90_ver | 134,135,136,137 | leakbatt1, …,leakbatt4 |
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&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&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
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 |
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).
the brackets ”[ ]“ are NOT supposed to be entered - they are just separators here for your ID and password to enter
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.
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.
——————————————————————————————————————————————————————————————
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 Ofset 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 vlues are shown. Contrary to the ecoitt.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.
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 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.
——————————————————————————————————————————————————————————————
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 also stores 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) |
——————————————————————————————————————————————————————————————–
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
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!
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 sensor should 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 aplphabetical 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
example for the Interceptor driver and the WS90 piezo rain data re-purposing the hail and hailRate databse 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-extension]] in your [GW1000] or [Interceptor] stanza in weewx.conf with the respective assignment(s)
2. create new database fields and assign the observations via a fieled-map-extention
—————————————————————————————————————————————————————————
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. |
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
————————————————————————————————————————————————————————————————-
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 | 80 |
Interval* | 8 |
*) or an interval of your choice: 8-600 seconds
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)
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
Rainfall display priority
————————————————————————————————————————————————————————————————-
14. APIs (application programming interfaces)
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.
Currently (February 2024) the following consoles have the EW-GW API:
displayless consoles/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 capable)
- GW2000 (latest Ecowitt gateway, sold together with the Ecowitt WS90 outdoor array as GW2001 station, also available as single gateway/console)
- 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
- WN19x0 and WN182x consoles (lightweight console)
- the WS3800/WS3900/WS3910 consoles
- the Ambient WS-1965 console
(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 | piezo yearly rain [1/10 mm] | 1D07 = 743.1 mm |
0x87: | 2 | piezo rain gain* [1/100] 0-4 mm/h | 00A5 = 1.65 |
“ | 2 | piezo rain gain* [1/100] 4-10 mm/h | 00A0 = 1.60 |
” | 2 | piezo rain gain* [1/100] 10-30 mm/h | 00A0 = 1.60 |
“ | 2 | piezo rain gain* [1/100] 30-60 mm/h | 00A0 = 1.60 |
” | 2 | piezo rain gain* [1/100] 60+ mm/h | 00B4 = 1.80 |
“ | 2 | (not used) | 0064 = 1.00 |
” | 2 | (not used) | 0064 = 1.00 |
“ | 2 | (not used) | 0064 = 1.00 |
” | 2 | (not used) | 0064 = 1.00 |
“ | 2 | (not used) | 0064 = 1.00 |
0x88: | 3 | time for piezo rain reset (RST) ** | 00 00 00 |
0x7A: | 1 | rain priority *** | 2 |
0x7B: | 1 | radiation compensation - on/off | not present |
last byte | 1 | checksum | E5 = 229 |
*) 5 calibration tiers WS90
**) Byte1: daily 0-23; Byte 2:weekly 0-6; Byte 3: yearly 0-11; default: 1,2,3 = 0
***) (classical or piezo) - 1 = classical, 2 = piezo
****) radiation compensation - on/off (not present in sample reading)
————————————————————————————————————————————————————————————————-
14.b Retrieval of live data from the local network via http call (local http API)
the call in the web browser [URI] is: http://IP-Address/get_livedata_info? inside the local network
(however, this only works with consoles/gateways that have the local Ecowitt Gateway API)
For all the consoles/gateways which have the local Ecowitt API and an inbuilt webserver (all except GW1000/WH2650) WS View Plus also retrieves the live data info via the http get_livedata_info call.
(as opposite to WS View [without “Plus”] which only queries the so-called “telnet API” via port 45000)
the latest http API documentation here (August 2024) including WH46 and WS85/WS90 start rain
gw110xgw200x-http_interface_20240826.docx
“common_list”: { id : ITEM_XXXX_list val : unit : Battery : } ITEM_XXXX_list :{ #define ITEM_INTEMP 0x01//Indoor Temperature (℃) 2 #define ITEM_OUTTEMP 0x02//Outdoor Temperature (℃) 2 #define ITEM_DEWPOINT 0x03//Dew point (℃) 2 #define ITEM_WINDCHILL 0x04//Wind chill (℃) 2 #define ITEM_HEATINDEX 0x05//Heat index (℃) 2 #define ITEM_INHUMI 0x06//Indoor Humidity (%) 1 #define ITEM_OUTHUMI 0x07//Outdoor Humidity (%) 1 #define ITEM_ABSBARO 0x08//Absolutely Barometric (hpa) 2 #define ITEM_RELBARO 0x09//Relative Barometric (hpa) 2 #define ITEM_WINDDIRECTION 0x0A//Wind Direction (360°) 2 #define ITEM_WINDSPEED 0x0B//Wind Speed (m/s) 2 #define ITEM_GUSTSPEED 0x0C//Gust Speed (m/s) 2 #define ITEM_RAINEVENT 0x0D//Rain Event (mm) 2 #define ITEM_RAINRATE 0x0E//Rain Rate (mm/h) 2 #define ITEM_RAIN_GAIN 0x0F//Rain gain (mm) 2 #define ITEM_RAINDAY 0x10//Rain Day (mm) 2 #define ITEM_RAINWEEK 0x11//Rain Week (mm) 2 #define ITEM_RAINMONTH 0x12//Rain Month (mm) 4 #define ITEM_RAINYEAR 0x13//Rain Year (mm) 4 #define ITEM_RAINTOTALS 0x14//Rain Totals (mm) 4 #define ITEM_LIGHT 0x15//Light (lux) 4 #define ITEM_UV 0x16//UV (uW/m2) 2 #define ITEM_UVI 0x17//UVI (0-15 index) 1 #define ITEM_TIME 0x18//Date and time 6 #define ITEM_DAYLWINDMAX 0X19//Day max wind(m/s) 2 }
the provided reply will look like the example below: (WS90)
{ “common_list”: [{ “id”: “0x02”, “val”: “29.8”, “unit”: “C” }, { “id”: “0x07”, “val”: “49%” }, { “id”: “3”, “val”: “30.5”, “unit”: “C” }, { “id”: “0x03”, “val”: “18.0”, “unit”: “C” }, { “id”: “0x0B”, “val”: “2.52 km/h” }, { “id”: “0x0C”, “val”: “6.12 km/h” }, { “id”: “0x19”, “val”: “23.40 km/h” }, { “id”: “0x15”, “val”: “451.30 W/m2” }, { “id”: “0x17”, “val”: “2” }, { “id”: “0x0A”, “val”: “178” }], “rain”: [{ “id”: “0x0D”, “val”: “0.0 mm” }, { “id”: “0x0E”, “val”: “0.0 mm/Hr” }, { “id”: “0x10”, “val”: “0.0 mm” }, { “id”: “0x11”, “val”: “39.8 mm” }, { “id”: “0x12”, “val”: “39.8 mm” }, { “id”: “0x13”, “val”: “816.5 mm”, “battery”: “0” }], “piezoRain”: [{ “id”: “srain_piezo”, “val”: “1” }, { “id”: “0x0D”, “val”: “0.0 mm” }, { “id”: “0x0E”, “val”: “0.0 mm/Hr” }, { “id”: “0x10”, “val”: “0.0 mm” }, { “id”: “0x11”, “val”: “36.3 mm” }, { “id”: “0x12”, “val”: “36.3 mm” }, { “id”: “0x13”, “val”: “823.5 mm”, “battery”: “5” }], “wh25”: [{ “intemp”: “26.5”, “unit”: “C”, “inhumi”: “60%”, “abs”: “981.7 hPa”, “rel”: “1016.1 hPa”, “battery”: “0” }], “lightning”: [{ “distance”: “37 km”, “date”: “2024-09-06T01:31:37”, “timestamp”: “09/06/2024 01:31:37”, “count”: “0”, “battery”: “3” }], “co2”: [{ “temp”: “23.8”, “unit”: “C”, “humidity”: “70%”, “PM25”: “3.3”, “PM25_RealAQI”: “14”, “PM25_24HAQI”: “11”, “PM10”: “4.8”, “PM10_RealAQI”: “4”, “PM10_24HAQI”: “3”, “CO2”: “745”, “CO2_24H”: “584”, “battery”: “6” }], “ch_pm25”: [{ “channel”: “1”, “PM25”: “4.0”, “PM25_RealAQI”: “17”, “PM25_24HAQI”: “29”, “battery”: “5” }, { “channel”: “2”, “PM25”: “4.0”, “PM25_RealAQI”: “17”, “PM25_24HAQI”: “77”, “battery”: “5” }], “ch_leak”: [{ “channel”: “2”, “name”: ”“, “battery”: “4”, “status”: “Normal” }], “ch_aisle”: [{ “channel”: “1”, “name”: ”“, “battery”: “0”, “temp”: “30.2”, “unit”: “C”, “humidity”: “50%” }, { “channel”: “2”, “name”: ”“, “battery”: “0”, “temp”: “35.2”, “unit”: “C”, “humidity”: “47%” }, { “channel”: “3”, “name”: ”“, “battery”: “0”, “temp”: “31.5”, “unit”: “C”, “humidity”: “46%” }, { “channel”: “4”, “name”: ”“, “battery”: “0”, “temp”: “29.8”, “unit”: “C”, “humidity”: “65%” }, { “channel”: “5”, “name”: ”“, “battery”: “0”, “temp”: ”-17.1“, “unit”: “C”, “humidity”: “None” }, { “channel”: “6”, “name”: ”“, “battery”: “0”, “temp”: “42.6”, “unit”: “C”, “humidity”: “43%” }, { “channel”: “7”, “name”: ”“, “battery”: “0”, “temp”: “8.5”, “unit”: “C”, “humidity”: “49%” }], “ch_soil”: [{ “channel”: “1”, “name”: ”“, “battery”: “5”, “humidity”: “38%” }, { “channel”: “2”, “name”: ”“, “battery”: “4”, “humidity”: “38%” }, { “channel”: “3”, “name”: ”“, “battery”: “4”, “humidity”: “43%” }, { “channel”: “4”, “name”: ”“, “battery”: “5”, “humidity”: “78%” }, { “channel”: “5”, “name”: ”“, “battery”: “4”, “humidity”: “65%” }, { “channel”: “6”, “name”: ”“, “battery”: “4”, “humidity”: “47%” }], “ch_temp”: [{ “channel”: “1”, “name”: ”“, “temp”: “20.0”, “unit”: “C”, “battery”: “3” }, { “channel”: “2”, “name”: ”“, “temp”: “12.0”, “unit”: “C”, “battery”: “5” }], “ch_leaf”: [{ “channel”: “1”, “name”: “CH1 Leaf Wetnes”, “humidity”: “17%”, “battery”: “5” }] }
in principle the “http/JSON” API allows for much more - all the activities shown in the menu of the WebUI and activities from the related sub-pages can be initiated or executed:
————————————————————————————————————————————————————————————————-
14.c Retrieval of sensor data from the local network via http call (local http API)
the call in the web browser [URI] is: http://IP-Address/get_sensors_info?page=1 and http://IP-Address/get_sensors_info?page=2 inside the local network
(however, this only works with consoles/gateways that have the local Ecowitt Gateway API)
For all the consoles/gateways which have the local Ecowitt API and an inbuilt webserver (all except GW1000/WH2650) WS View Plus also retrieves the live data info via the http get_livedata_info respectively the http get_sensors_info call.
(as opposite to WS View [without “Plus”] which only queries the so-called “telnet API” via port 45000)
inside the API response the different devices (sensors/sensor arrays) are numbered as type from 0 - 49 (decimal) [April 2024]
this is the maximal number of devices connected to a console
type (#) | sensor (array) | type (#) | sensor (array) | type (#) | sensor (array) | ||
---|---|---|---|---|---|---|---|
0 | WS69 | 20 | WH51 (7) | 40 | WH35 (1) | ||
1 | WS68 | 21 | WH51 (8) | 41 | WH35 (2) | ||
2 | WH80 | 22 | WH41 (1) | 42 | WH35 (3) | ||
3 | WH40 | 23 | WH41 (2) | 43 | WH35 (4) | ||
4 | WH25 | 24 | WH41 (3) | 44 | WH35 (5) | ||
5 | WH26 | 25 | WH41 (4) | 45 | WH35 (6) | ||
6 | WH31 (1) | 26 | WH57 | 46 | WH35 (7) | ||
7 | WH31 (2) | 27 | WH55 (1) | 47 | WH35 (8) | ||
8 | WH31 (3) | 28 | WH55 (2) | 48 | WS90 | ||
9 | WH31 (4) | 29 | WH55 (3) | 49 | WS85 | ||
10 | WH31 (5) | 30 | WH55 (4) | 50 | |||
11 | WH31 (6) | 31 | WH34 (1) | ||||
12 | WH31 (7) | 32 | WH34 (2) | ||||
13 | WH31 (8) | 33 | WH34 (3) | ||||
14 | WH51 (1) | 34 | WH34 (4) | ||||
15 | WH51 (2) | 35 | WH34 (5) | ||||
16 | WH51 (3) | 36 | WH34 (6) | ||||
17 | WH51 (4) | 37 | WH34 (7) | ||||
18 | WH51 (5) | 38 | WH34 (8) | ||||
19 | WH51 (6) | 39 | WH45 |
example:
http://IP-Address/get_sensors_info?page=1
[{ “img”: “wh85”, “type”: “49”, “name”: “Wind & Rain”, “id”: “FFFFFFFF”, “batt”: “9”, “signal”: “0”, “idst”: “1” }, { “img”: “wh90”, “type”: “48”, “name”: “Temp & Humidity & Solar & Wind & Rain”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh69”, “type”: “0”, “name”: “Temp & Humidity & Solar & Wind & Rain”, “id”: “30”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh68”, “type”: “1”, “name”: “Solar & Wind”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh40”, “type”: “3”, “name”: “Rain”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh25”, “type”: “4”, “name”: “Temp & Humidity & Pressure”, “id”: “63”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh26”, “type”: “5”, “name”: “Temp & Humidity”, “id”: “E7”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh80”, “type”: “2”, “name”: “Temp & Humidity & Solar & Wind”, “id”: “3002A”, “batt”: “5”, “signal”: “0”, “idst”: “1” }, { “img”: “wh57”, “type”: “26”, “name”: “Lightning”, “id”: “D947”, “batt”: “3”, “signal”: “4”, “idst”: “1” }, { “img”: “wh45”, “type”: “39”, “name”: “PM25 & PM10 & CO2”, “id”: “2D43”, “batt”: “6”, “signal”: “4”, “idst”: “1” }, { “img”: “wh41”, “type”: “22”, “name”: “PM2.5 CH1”, “id”: “B9”, “batt”: “9”, “signal”: “0”, “idst”: “1” }, { “img”: “wh41”, “type”: “23”, “name”: “PM2.5 CH2”, “id”: “46”, “batt”: “5”, “signal”: “4”, “idst”: “1” }, { “img”: “wh41”, “type”: “24”, “name”: “PM2.5 CH3”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh41”, “type”: “25”, “name”: “PM2.5 CH4”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh55”, “type”: “27”, “name”: “Leak CH1”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh55”, “type”: “28”, “name”: “Leak CH2”, “id”: “10E3E4”, “batt”: “4”, “signal”: “4”, “idst”: “1” }, { “img”: “wh55”, “type”: “29”, “name”: “Leak CH3”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh55”, “type”: “30”, “name”: “Leak CH4”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh31”, “type”: “6”, “name”: “Temp & Humidity CH1”, “id”: “5D”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh31”, “type”: “7”, “name”: “Temp & Humidity CH2”, “id”: “E”, “batt”: “0”, “signal”: “3”, “idst”: “1” }, { “img”: “wh31”, “type”: “8”, “name”: “Temp & Humidity CH3”, “id”: “CA”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh31”, “type”: “9”, “name”: “Temp & Humidity CH4”, “id”: “6C”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh31”, “type”: “10”, “name”: “Temp & Humidity CH5”, “id”: “7”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh31”, “type”: “11”, “name”: “Temp & Humidity CH6”, “id”: “F3”, “batt”: “0”, “signal”: “4”, “idst”: “1” }]
http://IP-Address/get_sensors_info?page=2
[{ “img”: “wh31”, “type”: “12”, “name”: “Temp & Humidity CH7”, “id”: “74”, “batt”: “0”, “signal”: “4”, “idst”: “1” }, { “img”: “wh31”, “type”: “13”, “name”: “Temp & Humidity CH8”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh51”, “type”: “14”, “name”: “Soil moisture CH1”, “id”: “C5E0”, “batt”: “2”, “signal”: “3”, “idst”: “1” }, { “img”: “wh51”, “type”: “15”, “name”: “Soil moisture CH2”, “id”: “C814”, “batt”: “5”, “signal”: “3”, “idst”: “1” }, { “img”: “wh51”, “type”: “16”, “name”: “Soil moisture CH3”, “id”: “C6D0”, “batt”: “5”, “signal”: “4”, “idst”: “1” }, { “img”: “wh51”, “type”: “17”, “name”: “Soil moisture CH4”, “id”: “C6A8”, “batt”: “5”, “signal”: “3”, “idst”: “1” }, { “img”: “wh51”, “type”: “18”, “name”: “Soil moisture CH5”, “id”: “D32DC”, “batt”: “4”, “signal”: “4”, “idst”: “1” }, { “img”: “wh51”, “type”: “19”, “name”: “Soil moisture CH6”, “id”: “D3354”, “batt”: “4”, “signal”: “4”, “idst”: “1” }, { “img”: “wh51”, “type”: “20”, “name”: “Soil moisture CH7”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh51”, “type”: “21”, “name”: “Soil moisture CH8”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “31”, “name”: “Temp CH1”, “id”: “3965”, “batt”: “4”, “signal”: “4”, “idst”: “1” }, { “img”: “wh34”, “type”: “32”, “name”: “Temp CH2”, “id”: “4E9B”, “batt”: “5”, “signal”: “4”, “idst”: “1” }, { “img”: “wh34”, “type”: “33”, “name”: “Temp CH3”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “34”, “name”: “Temp CH4”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “35”, “name”: “Temp CH5”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “36”, “name”: “Temp CH6”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “37”, “name”: “Temp CH7”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh34”, “type”: “38”, “name”: “Temp CH8”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “40”, “name”: “Leaf Wetness CH1”, “id”: “2A8B”, “batt”: “1”, “signal”: “4”, “idst”: “1” }, { “img”: “wh35”, “type”: “41”, “name”: “Leaf Wetness CH2”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “42”, “name”: “Leaf Wetness CH3”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “43”, “name”: “Leaf Wetness CH4”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “44”, “name”: “Leaf Wetness CH5”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “45”, “name”: “Leaf Wetness CH6”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “46”, “name”: “Leaf Wetness CH7”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }, { “img”: “wh35”, “type”: “47”, “name”: “Leaf Wetness CH8”, “id”: “FFFFFFFE”, “batt”: “9”, “signal”: “0”, “idst”: “0” }]
the “id” is the sensor ID of the signle sensor - if “FFFFFFFE” is shown, it means that no such sensor is connected
“idst” seems to mean id status: 1, connected - 0, not connected; “img” refers to the icon in the sensors ID page, “name” is the name under the icon;
“batt” is the battery status and depends on the sensor (see battery status)- 1 -5 in steps of 20% of capacity or respective voltage of 1.5V multiples, or 1 and 5 meaning low and normal, 6 = on DC, 9=off, “signal” the number of bars for past 4 subsequent successful packet reception
WH25 is the T&H sensor, WH26 is the T&HP sensor
———————————————————————————————————————————————————————————————-
14 d. retrieving data from the Ecowitt cloud (ecowitt.net) - data retention intervals - https API call
if you have an account at www.ecowitt.net (the Ecowitt cloud), you can have your Ecowitt (or clone except Ambient) consoles post there in a 1 - 5 minute interval. The data is displayed on the dashboard and refreshed every minute and stored every five minutes. You can have more than one console post to the same account. The console (device) is identified and selectable based on its MAC address.
This data can also be retrieved from the cloud via the so-called Ecowitt cloud API
(not to be confused with the Ecowitt Gateway API of the GW1x00/GW2000/WH2650/WN19x0/WS3800/WS39x0 consoles via which data can be retrieved directly from the console inside the same local network subnet).
Data is kept in the Ecowitt cloud for different periods at different intervals:
- 5 minutes resolution data within the past 90 days
- 30 minutes resolution data within the past 360 days
- 240 minutes resolution data within the past 730 days
- 24 hours resolution data since 2019.1.1
With a proper piece of software (or even manually), the data a console posted earlier can be retrieved by the help of an API key and an APP key - to be created in your account profile. Each one (API and APP key) needs to be created separately.
so far (April 2024) the CumulusMX and Weather Display datalogger software uses this API. For weewx it is rumoured to be under development.
the generic https call (URI to be entered into your browser) is:
https://api.ecowitt.net/api/v3/device/info?application_key=APPLICATION_KEY&api_key=API_KEY&mac=Your_MAC
pre-requisites:
- you have an account at ecowitt.net
- your console is registered at ecowitt.net via your account
- your console posts to eccowitt.net
- you have created an APP key and an API key in your profile
further details for developers can be found at https://doc.ecowitt.net
————————————————————————————————————————————————————————————————-
14 e. the local http IoT API
Not only the Ecowitt or the WS iew Plus app can communicate with a local Ecowitt IoT network via its hub but in principle any application which uses the local Ecowitt IoT API.
e.g HomeAssistant or FOSHKplugin or any other accordingly programmed application.
local_iot_api_20240828.docx
the context can be seen in the picture below - the WS View Plus icon in the picture below can be replaced by an application which is able to make the respective API calls.
see also
our IoT chapter
————————————————————————————————————————————————————————————————-
15. data export from the HP25x0 console
HP2551/HP2560 data archiving on a microSD card - as per device firmware version 1.8.0
(under earlier firmware versions there were different file names and also more individual files)
The HP2551 console saves the received sensor base data at the interval set by the user in the console.
The basic data is
Time,Indoor Temperature(℃),Indoor Humidity(%),Outdoor Temperature(℃),Outdoor Humidity(%),Dew Point(℃),
Feels Like (℃),Wind(km/h),Gust(km/h),Wind Direction(°),ABS Pressure(hpa),REL Pressure(hpa),Solar Rad.(w/m2),UVI,
Hourly Rain(mm),Event Rain(mm),Daily Rain(mm),Weekly Rain(mm),Monthly Rain(mm),Yearly Rain(mm)
(the naming is dependent on the selected display language)
and are stored in the internal memory. This has a size of 16 MB. If the memory is full, the oldest data record is overwritten.
If a microSD card is inserted, the console also writes data to the SD card, both the basic data and extra sensor data.
The extra sensors or their derived data (e.g. dew point) is:
Time,CH1 Temperature(℃),CH1 Dewpoint(℃),CH1 HeatIndex(℃),CH1 Humidity(%),CH2 Temperature(℃),CH2 Dewpoint(℃),CH2 HeatIndex(℃),CH2 Humidity(%),
CH3 Temperature(℃),CH3 Dewpoint(℃),CH3 HeatIndex(℃),CH3 Humidity(%),CH4 Temperature(℃),CH4 Dewpoint(℃),CH4 HeatIndex(℃),CH4 Humidity(%),
CH5 Temperature(℃),CH5 Dewpoint(℃),CH5 HeatIndex(℃),CH5 Humidity(%),CH6 Temperature(℃),CH6 Dewpoint(℃),CH6 HeatIndex(℃),CH6 Humidity(%),
CH7 Temperature(℃),CH7 Dewpoint(℃),CH7 HeatIndex(℃),CH7 Humidity(%),CH8 Temperature(℃),CH8 Dewpoint(℃),CH8 HeatIndex(℃),CH8 Humidity(%),
WH35 CH1hum(%),WH35 CH2hum(%),WH35 CH3hum(%),WH35 CH4hum(%),WH35 CH5hum(%),WH35 CH6hum(%),WH35 CH7hum(%),WH35 CH8hum(%),
Thunder count,Thunder distance,WH45 Temperature(℃),WH45 Humidity(%),WH45 CO2(ppm),WH45 Pm2.5(ug/m3),WH45 Pm10(ug/m3),
SoilMoisture CH1(%),SoilMoisture CH2(%),SoilMoisture CH3(%),SoilMoisture CH4(%),SoilMoisture CH5(%),SoilMoisture CH6(%),SoilMoisture CH7(%),SoilMoisture CH8(%),
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(℃)
i.e. the data from ALL sensors that can be registered on the console will be saved. If a sensor is not available, it is labelled ”–“ (”–“ is two minus signs, which the forum software may not display correctly)
The data is split into two CSV files (Comma Separated Values, values separated by a comma [or semicolon or tab]),
one for the basic data, one for the extra data. Monthly files are created.
Basic data: YYYYMMa.CSV YYYY=year, 4 digits, e.g. 2022; MM=month, two digits, e.g. 06; a= A, B, C ….; complete example 202206A.CSV
Extra data: YYYYMMAllsensors_a YYYY=Year, 4 digits, e.g. 2022; MM=Month, 2 digits, e.g. 06; a= A, B, C ….; complete example 202206Allsensors_A.CSV
If the SD card is removed during the course of a month, a new monthly file for the same month is created with the next capital letter when the card is reinserted.
e.g. 202206B.CSV and 202206Allsensors_B.CSV
Example extract from 202211Allsensors_A.CSV
2022/11/1 0:00,12.5,10.2,12.5,86,12.9,12.5,12.9,97,13.3,11.0,13.3,86,13.0,11.2,13.0,89,-17.6,–,–,–,12.8,11.6,12.8,92,5.4,-0.3,5. 4,67,-,-,-,-,-,1,-,-,-,-,-,-,-,0,20,20.8,60,373,4,4,83,66,43,64,-,-,-,-,-,Normal,-,-,-,9,13,-,-,-,-,-,-,-,-,-,-,-
2022/11/1 0:05,12.5,10.2,12.5,86,12.9,12.5,12.9,97,13.3,10.8,13.3,85,13.0,11.2,13.0,89,-19.4,–,–,–,12.8,11.6,12.8,92,5.3,-0.4,5. 3,67,-,-,-,-,-,-,-,-,-,-,-,-,0,20,20.8,60,393,5,5,5,84,66,43,64,-,-,-,-,-,Normal,-,-,-,9,13,-,-,-,-,-,-,-,-,-,-,-
2022/11/1 0:10,12.6,10.3,12.6,86,12.9,12.5,12.9,97,13.4,10.9,13.4,85,13.0,11.2,13.0,89,-19.9,–,–,–,12.8,11.6,12.8,92,5.1,-0.9,5. 1,65,-,-,-,-,-,5,-,-,-,-,-,-,-,0,20,20.3,61,422,5,5,83,66,43,64,-,-,-,-,-,Normal,-,-,-,9,12,-,-,-,-,-,-,-,-,-,-,-
When backing up the basic data stored in the console, all existing basic data is backed up.
\\A file is created with the name Backup-a.CSV, where a = A, B, C …. The letter is incremented by one (=next letter in the alphabet) with each backup.
e.g. Backup-A.CSV; Backup-B.CSV ….
The structure of the backup file is:
Time,Indoor Temperature(℃),Indoor Humidity(%),Outdoor Temperature(℃),Outdoor Humidity(%),Dew Point(℃),
Feels Like (℃),Wind(km/h),Gust(km/h),Wind Direction(°),ABS Pressure(hpa),REL Pressure(hpa),Solar Rad.(w/m2),UVI,
Hourly Rain(mm),Event Rain(mm),Daily Rain(mm),Weekly Rain(mm),Monthly Rain(mm),Yearly Rain(mm)
The respective data structure can be found in each file as a header (1st line)
Note: No data transfer to weather services or custom server destinations takes place during a backup. When the console memory is full, a backup may take longer than 10 minutes and, if set, may trigger an alarm from the Ecowitt dashboard.
————————————————————————————————————————————————————————————————-
16. Ecowitt Automation (IoT) - WFC01 ("Wittflow"), AC1100 ("Wittswitch")
introduction
Until recently (December 2023) the Ecowitt IoT devices only worked together with a GW2000. Meanwhile the GW1200, WN1980, WS3800 and WS39x0 consoles also support the IoT sensors.
The background is that bi-directional communication is necessary to control an “intelligent” component such as a switch.
A transmitter/receiver is used here that works in the sub-GHz range, like other sensors, with the difference that the typical weather related sensors are pure transmitters, while an IoT device must be able to do both. Sub GHz in Europe means using the licence-free ISM* bands, i.e. 868 MHz, in the Americas it's 915 MHz. The modulation methods used are often the same as for classic sensors. The possible methods and protocols also depend on the chip used. Sub-G only means that no WiFi (2.4 or 5 GHz), no Bluetooth or ZigBee is used. Apparently, in the beginning, the GW2000 was the only Ecowitt console that could also transmit in the direction of the IoT sensors.
*) ISM: industrial, scientific and medical
see also an interesting article on sub-GHz communication at External Link
The Ecowitt IoT devices can only be managed/configured via the Ecowitt app - details see farther down
The status of the IoT devices can also be viewed in the Ecowitt dashboard at ecowitt.net
The Ecowitt IoT devices work in three modes or three types of plans can be configured:
- manual mode (activities manually started/stopped in the app [WS View Plus or Ecowitt app])
- scheduled mode/plans (activities configured with a start/end/repetition - EW app; WSV+ planned)
- smart mode/plans (overriding or modifying scheduled plans based on sensor values)
for more details see below examples for the WFC01
—————————————————————————————————————————————————————————————————–
communication between Ecowitt app, Ecowitt cloud, IoT hub and IoT device
why is an internet connection needed in the first place ? - Because the configuration tool, the Ecowitt app, only works when connected to the user account in the Ecowitt cloud. There the IoT device gets registered as a subdevice of the cloud device and is configured from there via the hub.
the commands (switch on/off), scheduled plans (start at a time, day, repetitive … - stop at time, after time or consumption amount, e.g. volume of water flown) and smart plans (execution when conditions based on sensor readings are met) are sent via the Ecowitt app to the IoT hub which transfers them to the IoT device. In case of a smart plan the hub monitors the conditions and sends start of smart plan execution command to the IoT device.
Once the plans are created and submitted to the hub, the internet connection is only needed for monitoring the plan execution with the Ecowitt app and for storing the logs. If the internet connection is not available, the Ecowitt app can no longer work and the logs cannot be sent to the cloud server either.
However the plans can still be executed as long as sensors, hub and IoT device are active.
If the connection between hub and IoT device is no longer available, scheduled plans (which are also stored in the IoT device) can/will still be executed.
a few general remarks regarding internet connectivity and the use of the IoT sensors/devices:
1. to create scheduled or smart plans and to transfer them to the IoT device via the hub (GW2000, WN1980, WN182x, WS3800/WS39x0), an internet connection is needed. Once stored in hub and IoT device, they are executed as long as a connection to the hub exists.
2. scheduled plans are executed once stored on the IoT device
3. the IoT device cannot be manually (=via app) be switched on/off when no internet connection exists. Ecowitt have realized that there is a potential safety issue. They now want to implement this manual switch on/off (and possibly also smart and scheduled plans) via WS View Plus in a future upgrade from inside the local network.
4. regarding the IoT API : see the local Ecowitt IoT API
5. logs for activities during lack of internet access are lost
Note (20-May-2024)
with the upcoming new GW2000 firmware 3.1.3 and WS View Plus app upgrade (> 2.0.49) it will be possible to switch IoT devices on and off also locally, without the Ecowitt app which needs an active internet connection. This is to allow for an emergency shutdown/switch off of the devices in case of no internet connection and the need to switch off when a manual (physical) option is not available or not timely enough.
with firmware 3.1.3 a GW2000 can locally manage connected IoT devices in manual mode (scheduled and smart plan modes are not supported) from a new page in the WebUI - the WS View Plus app is expected to follow soon
when an IoT device is (or was formerly) registered to the respective GW2000, a menu point “IoT Devices” appears in the WebUI.
1. formerly registered and now no longer (or batteries expired)
2. actually registered to the GW2000
(below - switching a WFC01 manually on and off inside the local network)
———————————————————————————————————————————————————————————–
16 a. the WFC01 intelligent water timer, valve (WittFlow)
a timer-controlled or sensor-measurement-dependent* controllable water valve - IoT (Internet of Things) sensor
( * WFC01, WH51, WH40, and in principle all sensors registered on the GW2000).
The sensor/device has a built-in liquid flow sensor and a temperature sensor for the liquid temperature (water in this case). It also has a valve that can be opened or closed. The switching status of the valve, the water temperature and the flow rate are transmitted to the console. The transmission interval is still unknown (Ecowitt writes: “in real time” - the noticeable “reaction time” is ⇐ 1 second).
The WFC01 is controlled/configured with the Ecowitt app (version >= 1.1.25). It can also be switched on/off manually.
When mounting, the direction of water flow (arrow on the back) must be taken into account.
Due to the design of the Ecowitt app an active internet connection is necessary for it to operate.
Generally, the valve is opened or closed according to a (time) schedule.
The WFC01 has four operating modes, which differ in the scope of performance:
(1) Timer Button Mode (i.e. the valve is switched via the button on the unit).
(2) Manual Watering Mode (the valve is switched on and off via the Ecowitt App with a click, whereby there are three sub-modes)
(2.1) Turn on and off by duration [selectable between 10-43,200 seconds or 1- 720 minutes].
(2.2) Switch on and off via quantity (throughput)
(2.3) Always on (until switched off either by app or manually at the unit)
(3) Plan mode - here, up to 24 plans (=on/off times) can be defined, whereby here, too, a choice can be made between duration or quantity (throughput).
(4) Smart mode, also called automation, (not yet contained in the manual yet).
here, existing modes/schedules can be overwritten/skipped, e.g. depending on WH51 and/or WH40 sensor values. The prerequisite is the use of the Ecowitt Cloud.
In principle, the readings of all Ecowitt sensors can be defined as triggers.
A water consumption log is saved in the cloud and visible in the Ecowitt app
smart mode use case example:
If the switch/timer is used for outdoor watering, it makes little sense to also water when it rains.
If the water is too cold, it is counterproductive to water with it for certain plants.
The WFC01 is tested to a water pressure of up to 0.9 MPa, is waterproof and dustproof to IP66 and built from corrosion-resistant material. Together with the bracket and batteries (2 x AA), it weighs in at a hefty ~650 g. So it's no lightweight.
On 31 July 2023, Ecowitt released the GW2000 firmware 3.0.5, which also allows the WFC01 to be used (together with the Ecowitt App). In the Ecowitt App, the WFC01 can be set up as a subdevice (see pictures below), after which the connection page (pairing, see below) is accessed. After successful pairing, the WFC01 is displayed in the Ecowitt app (but so far not in the cloud browser view - and this doesn't seem to be planned so far either ). When you click/tap on the tile, the configuration dialogue appears. There you can select PLAN, SMART or LOG - see below for examples.
According to current information, sixteen (16) WFC01 (“Wittflow”) devices can be managed per GW2000.
(text continues after the pictures !!)
The plans and the manual instructions (mode 2 and 3) are sent by the GW2000 to the WFC01 where they are stored when they are saved in the Ecowitt app. Even if the WFC01 loses contact with the GW2000 (e.g. power loss of the GW2000), the plans will still be executed resp. the manual instruction will be completed once the completion criterion is met as the sensor runs on its own batteries.
If the battery level of the WFC01 drops below one bar (5 bars available to indicate the charging status), the valve switches automatically off.
below a view of the inner life of a WFC01
a few further remarks/insights here: (status March 2024)
1. to create smart plans and to transfer them to the IoT device via the hub (GW2000, WN1980, WN182x, WS3800/WS39x0), an internet connection is needed. Once stored in hub and IoT device, they are executed as long as a connection to the hub exists.
2. scheduled plans are executed once stored on the IoT device
3. the IoT device cannot be manually (=via app) be switched on/off when no internet connection exists. Ecowitt have realized that there is a potential safety issue. They now want to implement this manual switch on/off (and possibly also smart and scheduled plans) via WS View Plus in a future upgrade from inside the local network.
4. regarding IoT API: in a recent conversation the following statement was made: “there is no such manual (for the ) API available.” For how long this is valid is still to be seen.
5. logs for activities during lack of internet access are lost
————————————————————————————————————————————————————————————————-
16 b. the AC1100 intelligent switch (WittSwitch)
the AC1100 intelligent switch (WittSwitch)
The AC1100 smart plug is a switchable socket (adapter plug) that can be switched manually, time-controlled or based on measured values from the weather station.
The device can only be operated automatically with an IoT-enabled console (GW1200, GW2000, WN1980, WN1820, WS3800, WS39x0) and the Ecowitt app, just like the smart water valve WFC01.
The manual that now exists lists a device for continental Europe (868 MHz), for the United Kingdom (UK plus Northern IRL, 868 MHz), for the USA (915 MHz) and for Australia (433 MHz) with corresponding plugs and different maximum wattages . A Schuko plug is provided for continental Europe, 100-240 V, 16 A, max. 3,500 W power consumption (the maximum current and thus the max. power consumption are different for the other areas of application [USA 1,440W, AUS 2,300W, UK 3,000W]).
Voltage (V) and power (W) are displayed (in the Ecowitt app!), so far no temperature.
the main AC1100 user interface in the Ecowitt app
- signal quality
- input voltage
- power consumption
- running time of current program
- program time
- current status
- enter log diary and alert notification
- enter Plan Mode
- enter Smart Mode
- other information
- current power
- usage of current program
- switch on/off
- total runtime of current program
The AC1100 works in the same way as the WFC01, the intelligent water valve (see above), except that here it is not a valve that is opened or closed but a switch and either current flows or none flows.
below the inner life of a AC1100
a few further remarks/insights here: (status March 2024)
1. to create smart plans and to transfer them to the IoT device via the hub (GW2000, WN1980, WN182x, WS3800/WS39x0), an internet connection is needed. Once stored in hub and IoT device, they are executed as long as a connection to the hub exists.
2. scheduled plans are executed once stored on the IoT device
3. the IoT device cannot be manually (=via app) be switched on/off when no internet connection exists. Ecowitt have realized that there is a potential safety issue. They now want to implement this manual switch on/off (and possibly also smart and scheduled plans) via WS View Plus in a future upgrade from inside the local network.
4. regarding IoT API: in a recent conversation the following statement was made: “there is no such manual (for the ) API available.” For how long this is valid is still to be seen.
5. logs for activities during lack of internet access are lost
————————————————————————————————————————————————————————————————-
17. Ecowitt outdoor sensor arrays
There are so far (October 2023) five different outdoor arrays offered by FineOffset/Ecowitt as part of a station - see also chapter 6. Console (WiFi) + sensor combinations / packages (“stations”) - pictures see matrix resp. the respective sensor chapter
WN67
the WN67 is a 5-in-1 leightweight outdoor array with four sensors (wind speed, wind direction, outdoor temperature/humidity, rain) and it provides five readings: outdoor temperature, outdoor humidity, wind speed, gust speed and wind direction. It has NO solar sensor and NO solar panel (WN means no solar panel !). It runs on battery only and transmits its readings every 16 seconds.
There is a battery pack for the WN67 with a 10m extension cord for easier battery exchange (sold as WS69 accessory)
WH65/WS65/WS69
The WS69 and the WS/WH65 array come with two different designs: WS65 (older design) - Y-shape or osprey shape with the wind reading sensors at the bifurcation end - and the WS69 (newer design) - I-shape with the wind and wind direction sensors above each other, where also two variations exist (old: cups up, vane down and new: cups down, vane up). All three designs are current sold with different consoles as starter stations by Ecowitt and different resellers: WS2320E, WH2910, HP3501, HP25x1, GW1101, WH2650, WS6006.
There is a battery pack for the I-shape model (WS69) only with a 10m extension cord originally built for the WN67.
The battery pack won't work with a WH65 Y-shape design model.
The WS65/WS69 array is a 7-in-1 array: 5 sensors - 7 readings (wind speed/gust/direction, solar + UV, T/RH, rain). It has a solar panel and an inbuilt supercapacitor as energy storage (“battery”). Its transmission interval is 16 seconds.
WS68
The WS68 array is a 5-in-1 array: 3 sensors - 5 readings (wind speed/gust/direction and solar + UV)
It has a solar panel and an inbuilt supercapacitor as energy storage (“battery”). Its transmission interval is 16 seconds.
WS80
The WS80 array is a 6-in-1 array: 3 sensors - 6 readings (wind speed/gust/direction, solar, outdoor T/RH).
It has a solar panel and an inbuilt supercapacitor as energy storage (“battery”). Its transmission interval is 4.75 seconds.
Its anemometer is based on ultrasonic measurement of wind speed and direction. In its latest hardware revision its pluggable outdoor T/RH sensor with a bluish plug end (type3, SHT31/40 sensor) can be replaced by a high precision SHT35 T/RH sensor.
It contains a thermostate triggered heater plate to allow for ultrasonic measurements below 0° C / 32° F with a 12V/1 A power supply. When connected to an external power source, the whole array runs on external power.
When the heater is running, the outdoor temp/hum readings can be affected - up to +3° C have been observed. It depends on how much the temperature falls below 0° C and how long the heater runs each time as it is not running permanently and not with the same amount of power consumption. The same applies to a WS90.
WS90 / WS85
The WS90 array is a 7-in-1 array: 4 sensors - 7 readings (wind speed/gust/direction, solar, outdoor T/RH, rain).
It has a solar panel and an inbuilt supercapacitor as energy storage (“battery”). Its transmission interval is 8.8 seconds.
Its anemometer is based on ultrasonic measurement of wind speed and direction. In its latest hardware revision its pluggable outdoor T/RH sensor with a bluish plug end (type3, SHT31/40 sensor) can be replaced by a high precision SHT35 T/RH sensor.
It contains a thermostate triggered heater plate to allow for ultrasonic measurements below 0° C / 32° F with a 12V/1 A power supply. When connected to an external power source, the whole array runs on external power.
Regarding impact on outdoor temperature readings, see above WS80.
The WS85 is a WS90 without solar sensor, outdoor T/RH readings and without an inbuilt heater/external power supply: a Wind & Rain array - the haptic rain sensor (improved top design) and the ultrasonic anemometer are the same as with the WS90
The WS90 has a haptic (“piezo”) rain detector/counter/gauge which can be calibrated in five different tiers depending on rain rate.
Until October 2023 the rain readings, especially at low and very low rain rates (tier 1 and 2), show a non-linear behaviour which is still to be improved by an optimized characteristic line (→ firmware). Otherwise the linear tier calibration will not properly compensate its over- or underreadings observed so far.
Therefore, for high accuracy, an additional WH40 rain gauge with a 3D printed rim height extension (https://www.wxforum.net/index.php?topic=44074) is recommended. The WS90/WS85 rain readings can be shown synoptically with the WH40 or WS69 rain readings in the WS View Plus app or the WebUI (with a GW1x00/GW2000/WN19x0 console) and in the Ecowitt cloud dashboard (ecowitt.net) or in the Ecowitt app as separate tiles.
wind readings
WH24 - “the boat” - outdoor array legacy model
sampling interval 16 seconds, however only the last 8 seconds are measured; sampling rate: 1 Hz, gust: highest wind value of the past 8 samplings
wind measurements by the different outdoor array anemometers
a) general
there are five important terms in the context of wind readings/measurements for Ecowitt anemometers
1. sampling rate (how often a measurement is made inside the sampling interval, as for Ecowitt 1 Hz = one per second)
2. sampling interval (time in which the sampling takes place before a result is transmitted)
3. transmission interval (as a rule the same as sampling interval for current wind speed and direction - between 2 and 48 seconds)
4. definition of gust (highest wind speed within the past 28 seconds)
5. transmission value (the last value in the sampling interval = transmitted wind speed, gust and direction)
6. (for ultrasonic anemometers) at wind speeds lower than 5m/s, the dispersion of wind direction will increase
WN67: sampling interval 16 seconds, sampling rate: 1 Hz, gust: highest wind value of the past 16 samplings
WS65/WS69: sampling interval 16 seconds, sampling rate: 1 Hz, gust: highest wind value of the past 16 samplings
WS68: sampling interval 16 seconds, sampling rate: 1 Hz, gust: highest wind value of the past 16 samplings
WS80: sampling interval 4.75 seconds, sampling rate: variable, gust: highest wind value in the past 28 seconds
details:
when max wind speed in the past 4 seconds is >= 5 m/s, the sampling rate is 1 Hz
when max wind speed in the past 4 seconds is >=3 m/s and < 5 m/s, the sampling rate is 2 Hz
when max wind speed in the past 4 seconds is < 3 m/s, the sampling rate is 4 Hz
WS90: sampling interval 8.8 seconds, sampling rate: 2 Hz, gust: highest wind value in the past 28 seconds
WS85: the sampling interval is 8.5 seconds, sampling rate: 2 Hz; gust: highest wind value in the past 28 seconds
————————————————————————————————————————————————————————————————-
18. Passive Solar Radiation Shields/shelters - Stevenson screens
temperature or temperature/humidity sensors should not be exposed to direct solar irradiation but be protected in a solar radiation shield or so-called Stenvenson screen.
Ecowitt offers a temperature compensation functionality in its consoles/gateways (all but WS2320 and WS2910) to compensate for the small size of the WS69/WS80 and WS90 outdoor arrays and insufficient airflow. The compensation is switched on in either the console setup page (HP25x0, HP350x) or via the WS View plus app / WebUI of the consoles with the local Ecowitt API ([More} –> Device Settings –> Temperature compensation).
For a WH32 outdoor T/RH sensor or WH31-family extra T/RH sensors the use of a proper radiation shield is recommended when they are exposed to direct solar irradiation !
Not everything what looks nice is a good radiation shield though.
The main challenges for a proper temperature (and humidity) reading are:
- direct and indirect solar irradiation heating the sensor housing and raising the temperature too high
- insufficient airflow around the sensor (also inside a shield) transferring excess heat from the shield to the sensors (overreading)
- air getting stuck in the upper portion of the shield creating an air bulb (overreading)
- air not moving fast enough to show the changes in temperature and humidity outside (underreading)
There are passive radiation shields or actively ventilated/aspirated radiation shields. Here we will deal with passive shields only as they are usually sufficient. The very good ones are even better than many ventilated models.
there is a long thread/topic at wxforum.net where one of our Italian weather enthusiasts (@Ivano) has compared common passive radiation shields, including a few of those described hereafter: https://www.wxforum.net/index.php?topic=39934.0
————————————————————————————————————————————————————————————————-
Barani MeteoShield Pro
The Barani MeteoShield Pro is an excellent professional passive radiation shield for sensor probes.
The quality and performance also has its price: ~ 230 EUR / 250 USD (February 2024).
It uses a patented design where the shield segments are not horizontally put one above the other but show a triple-helix design which produces an excellent airflow and reaction time on changes in temperature and humidity, prevented amongst other things hot air bulbs from building up at the top. The design also keeps dirt from entering the shield to quite a large degree.
A description of how to use a Barani MeteoShield Professional with a WH32-EP or a WH31-EP can be found at the Barani website FAQs: https://www.baranidesign.com/faq-articles/2022/8/01/how-to-properly-mount-an-ecowitt-temp-humidity-sensor-inside-the-meteoshield-pro
A detailed description/data sheet of the MeteoShield Pro: meteoshield-professional-datasheet.pdf
————————————————————————————————————————————————————————————————-
MetSpec Rad02
The MetSpec Radxx screens are produced in the UK - and it appears that they mainly serve business customers like institutions. It had been difficult to order a screen from them. Recently some wxforum.net forum member launched an order from Portugal for people based in continental Europe. The price comes down to ~160 EUR shipping and import duties included.
MeteoSpec offers different screens/shelters, most for probes only. The MetSpec Rad02 is +/- the only model with enough space where also a WH32 or WH31 sensor can be put inside. The performance is quite good, even though depending on the angle sunlight falls on the shield, the underside of the staggered elements needs to be painted black to avoid too much impact of the solar radiation. It occurs especially when the sun is standing rather low in winter time.
For more test results see the wxforum.net thread https://www.wxforum.net/index.php?topic=39934.0.
A detailed description/data sheet of the MetSpec Rad02: metspecradshielddatasheet-3.0.pdf
————————————————————————————————————————————————————————————————-
Davis 7714
price-wise the Davis 7714 passive solar radiation shield ranges around 100 USD/100EUR.
It can easily house the probe of a WH32-EP, WH31-EP or of a WN30/WN34L sensor.
As for the sensor hosuing of a WH32 outdoor, WH31 etc. (for corresponding Ambient or Froggit sensor names see the console/sensor matrix) it has rather little space.
The housing of the normal WH32/WH31 sensors will only fit in when the sensor is tilted - which won't affect its readings.
It shows a rather nice and reasonable performance and is worth the investment.
More details - see link farther down.
For more test results see the wxforum.net thread https://www.wxforum.net/index.php?topic=39934.0.
————————————————————————————————————————————————————————————————-
Ambient Weather SRS100LX
AcuRite 06054M
Ecowitt RS0001 / Ambient WH31-SRS
This shield CANNOT be recommended as a solar radiation shield when exposed to direct sunlight. It then shows a poor performance. In a well aired and permanently shadowed area it can be used for a temperature sensor.
The recommendation is to use this shield for protection against rain and debris, e.g. for a WH57 lightning sensor it is meanwhile sold with.
sold by GARNI as GARNI RS1, by Froggit as RS0001
————————————————————————————————————————————————————————————————-
TFA 98.1111.02 solar-ventilated radiation screen
This screen not only promises to protect a temperature or thermo-hygro transmitter (sensor) from sun and rain, the built-in fan should enable more precise readings even in direct sunlight. The fan is powered exclusively by the solar panel. The permeable design of the protective cover and the air circulation inside generated by the fan are supposed to prevent hot air from building up and falsifying the measurement results.
The design looks promising, the price in Europe is between 25-30 EUR. Test results still pending ….
see also TFA review
————————————————————————————————————————————————————————————————-
19. Accessories
For the WS69/WH65 array follow link
——————————————————————————————————————————————————————————————
WH40 rim extensions
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 rain with strong winds.
3D printed height extension
A 5-6 cm high attachment created with a 3D printer (or the attachment of rigid plastic film of the same height) significantly improves the measurement result.
the print file (slt format) can be found in the attached archive wh40higherwall.zip
a detailed description can be found at https://www.wxforum.net/index.php?topic=44074
Ecowitt combined bird spikes/height extension
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 (bird spikes) attachment. If you do not already have the bird spikes, you must order both for this solution to work.
the Ecowitt solution improves the rain readings, however, not as much as the 3D printed approach with double the height.
rain gauge funnel protection
for protection against debris (e.g. leaves)
——————————————————————————————————————————————————————————————
WS80/WS90 external power supply
the external power supply provides 12 V / 1 A for running the newer hardware revisions of the WS80 and of the WS90. Not only does it run the whole sensor array but also the inbuilt heater when the temperature falls below 0° C / 32° F.
There are two options for the array / power supply connection: 10 m and 20 m.
If the WS90 array is mounted on a hollow mast/pole/pipe, the power supply cable can be put inside the pole. The fixing mechanism allow for moving the cable inside. Unpacked from the box the cable is outside.
Of course the voltage available for the heater will be less with the 20 m extension: ~ 10 V.
The heater runs in intervals depending on how low the temperature is.
Once the temperature goes above 3° C / 38° F, the heater switches off again until the temperature falls again below 0° C / 32° F.
————————————————————————————————————————————————————————————————-
20. Specifications
to be completed
consoles
accuracy of air pressure sensors used in the different consoles (source: manuals, Ecowitt product web pages; March 2024)
- WS3xx0: ±1.5 hpa (absolute pressure); ±2hpa (relative pressure)
- WN182xC: ±1.5hpa (absolute pressure); ±2hpa (relative pressure)
- WS2910: ±3 hPa
- WS2320: ±3 hPa
- WN19x0C: ± 5hPa
- HP2560C: ± 5hPa
- WH32B/WN32P: ± 5hPa (thus HP255xC, HP350xC, WH2650, WH2682)
- GW1100: ± 5 hPa
- GW1200: ± 3 hPa
- GW2000: ± 5 hPa
- WS6006: +/-3hpa
sensor arrays
Model WS69 / WH65 / WN67 |
---|
comes with WS2320, WS2910 (WS-2902), HP25x1, GW1x01, WS3800 |
Measurement | Range | Accuracy | Resolution |
---|---|---|---|
Wind speed | 0m/s to 50m/s | ±1 m/s (speed < 10 m/s); ± 10% (speed ≥ 10 m/s) | 0.1m/s |
Wind direction | 0° to 359° | ± 15° | 1° |
Temperature | -40°C to 60°C | ±0.3°C (± 0.6°F) | 0.1°C (± 0.1°F) |
Humidity | 1% to 99% | ±3.5% | 0.01 |
Light* | 0 Klux to 200 Klux | ±25% | 0.1Klux |
UVI* | 1~15 | ±2 | 1 |
Rain | 0~9999 | ± 10% | 0.254 mm (for volume < 1,000 mm) 1 mm (for volume ≥ 1,000 mm) |
*) not WN67
Model WS80 |
---|
comes with HP25x3, GW1x03 |
Measurement | Range | Accuracy | Resolution |
---|---|---|---|
Wind speed | 0m/s to 40m/s | <10m/s, ±0.5m/s; ≥10m/s, ±5% | 0.1m/s |
Wind direction | 0° to 359° | <10m/s, TBD, ≥10m/s, ±15° | 1° |
Temperature | -40°C to 60°C | ±1° C (± 0.6°F) | 0.1°C (± 0.1°F) |
Humidity | 1% to 99% | ±5% | 1 % |
Light | 0 Klux to 200 Klux | ±25% | 0.1Klux |
UVI | 1~15 | ±2 | 1 |
Model WS90 |
---|
comes with HP25x4, WN1980 |
Measurement | Range | Accuracy | Resolution |
---|---|---|---|
Wind speed | 0m/s to 40m/s | <10m/s, ±0.5m/s; ≥10m/s, ±5% | 0.1m/s |
Wind direction | 0° to 359° | <2m/s, ±10°; ≥2m/s, ±7° | 1° |
Temperature | -40°C to 60°C | ±0.3°C (± 0.6°F) | 0.1°C (± 0.1°F) |
Humidity | 1% to 99% | ±3.5% | 1 % |
Light | 0 Klux to 200 Klux | ±25% | 0.1Klux |
UVI | 1~15 | ±2 | 1 |
Rain | 0~9999 | TBD | 0.1 mm |
Model | WS85 | Wind speed Metering resolution | 0.1m/s (starting speed > 0.5m/s) |
---|---|---|---|
Dimensions | 93*93*126mm | Wind direction Metering range | 0° to 359° |
Dimensions With Bracket | 160*93*161mm | Wind direction Metering accuracy | ±15° |
Weight | 350g | Wind direction Metering resolution | 1° |
Material of Plastic Casing | ASA+PC、PC | Data reporting Interval | 8.5s |
Rainfall Metering range | 0mm to 9999mm | RF Connection Frequency | 920/915/868/433MHz (depending on local regulations) |
Rainfall Metering accuracy | <5mm/h (±20%) | RF Wireless Range (in open areas) | Over 150 meters (500 ft.) |
5mm/h~50mm/h(±10%) >5 0mm/h(±20%) | Operating Temperature Range | -40°C to 60°C (-40℉ to 140℉) |
|
Rainfall Metering resolution | 0.1mm | Protection Rating | IPX5 |
Wind speed Metering range | 0m/s to 40m/s | (Backup) Power Supply | 2*AA batteries |
Wind speed Metering accuracy | <10m/s, ±1m/s; ≥10m/s, ±10% | Battery Life | 1 Year |
Built-in Solar panel | 7.5V ±5%/30mA ±10% | ||
other sensors (1, 2-in-1, 3-in-1, 5-in-1)
to be completed
————————————————————————————————————————————————————————————————-
21. Converting WH31, WH32, WH32B sensors into one another
Since the WH31, WH32, WH32B sensors have the same PCB (printed circuit board), they can be converted into each other with a hardware intervention (by [re]soldering)
There are several options that have been successfully tested and documented in the meantime
1. WH31 –> WH32
2. WH32 –> WH31
3. WH32B –> WH31
(obviously neither WH31 nor WH32 can be converted into a WH32B/WN32P due to the missing pressure chip)
Depending on the production date of the sensor, there are also two PCB designs: old and new
Below are the transformations carried out so far (description and images)
If you want to convert a WH32B into a WH31, the channel must also be soldered accordingly (example see channel 8 below)
For a better understanding - Ecowitt continues to use the old sensor designations internally for the sensors of that time. WH24 for WH65/WS69, WH25 for WH32B, WH26 for WH32, WH31 has no predecessor
However, the new consoles can still receive old sensors (WH24, 25, 26) and cannot distinguish whether it is the old (predecessor) model or the newer model (WH65/WS69, WH31, WH32 [outdoor], WH32B [indoor])
see also note under WH24, the “boat” above
————————————————————————————————————————————————————————————————-
22. FAQs
overview
what is a rain event ?
what is a rain event ? - click on link
————————————————————————————————————————————————————————————————-
how do I connect/register new sensors to my console/gateway ?
there are two ways how to register new sensors
1. automatic
2. manual (recommended)
1. automatic registration
just bring the sensor close (~1 m, 3 feet) to your console and insert the batteries. The console should find it and register it in the sensor type section. For a sensor whose type can only be one per console (e.g. T&H, T%HP, WH45/46, WH57 …) or if it's the first sensor of a sensor type group, this is simple. However, you do not know in what position/channel of a sensor type (two groups WH41/43 and WH55 can have four, others up to eight sensors of the same type) and the console may register it anywhere - and you may not like that, because you want to assign a meaning to each sensor (like place, position etc.).
An exception are the sensors of the WH31 family (WH31, WN30, WN36) - they have dip switches for the channel to be used inside the battery compartment (see reverse side of the sensor housing - open the battery cover).
2. manual registration (recommended)
first of all, deactivate/disable all sensors which you do not have/use.
There are two types of consoles:
a. consoles with the local network API
(they can be configured with the WS View Plus app or with their WebUI in a web browser [https://IP-address-of-your-console] )
b. consoles without the local network API (WS2320*, WH2910, WS6006, HP25x0, HP350x)
they have to be configured on the SensorID page in the console setup
*) cannot have extra sensors beyond the outdoor array
in either case the deactivation (and later on the active registration) will be done on this SensorID page
for the consoles with API it can be found at WS View Plus “More”–> SensorsID, WebUI –> SensorsID.
For the deactivation click/tap on the “Edit” button or pen symbol for the sensor, choose “disable” and “save”. A “success” message should show.
for the registration of the new sensor (if you have more than one to register, repeat the procedure step by step) bring the sensor close (~ 1 m, 3 feet) to the console/gateway and tap/click on “Re-Register” for the place (channel) you want the sensor to be registered to. Then insert the battery. Now the sensor should be registered by the console at the desired position.
If it doesn't work and the sensor has its sensorID printed on a sticker, click on the “Edit” button, enter the sensor ID into the entry field and press “save”. A “success” message should pop up and after some time a battery symbol and reception bars should become visible.
see also how to connect sensors to multiple gateways or channels using their sensor ID
how to use more than 4 respectively 8 or 16 sensors of one type
the number of sensors you can receive with a single console is limited (see maximum number of sensors)
if you want to use more than 4 WH41, WH55 or more than 8 WH31, WN34, WN35 or more than 16 WH51 sensors, you will have to use a second console/gateway and register the new (e.g. #9 - #16 of a WH31 extra temperature/humidity) sensor to the second console.
Only the IoT enabled consoles support 16 WH51 (Soil Moisture) sensors - the others remain limited to eight.
Therefore the above WH31 example may also apply to WH51 sensors regarding the maximum number.
A smart way to do this is to deactivate/disable all the sensors, e.g. WH51, and then connect them one after the other by entering their sensor ID on the sensor ID page of the console, WebUI or WS View Plus app. The sensorID is usually printed on a label which is glued to the sensor.
We recommend to make a copy of the SensorID page afterwards to be able to restore the sensors to the proper console and in the proper (chosen by you) sequence in case this configuration gets lost (e.g. factory reset)
the different readings from the different consoles can be integrated into one view by using datalogger software like e.g. Meteobridge, weewx or Homeassistant (listing not complete).
A different approach which can even allow you to have multiple e.g. WH57 lightning sensors or the data of different sensor arrays in parallel (WH69, WS80, WS85, WS68, WS90) which are usually excluded by the sensor hierarchy (see Sensor Hierarchy is to use an SDR (software defined radio).
We know of an extreme case of a user who with this approach depicts 56 WH51 soil mositure sensors in his HomeAssistant installation without using a (second) Ecwoitt console.
this approach needs some deeper knowledge, will need to install and to run the software portion of the SDR, collect the data and transfer it to the archive and presentation place (e.g. HomeAssistant). There are also weewx solutions existing for that - at least in principle. They are likely needed to be extended and adapted to the number and type of sensors
—————————————————————————————————————————————————————————————–
how do I make my own website
there are many ways how to create your own weather web pages on your own website
- use an existing ready-made weather website template
- use a customizable weather website template from widgets, blocks, plugins
- create your own weather web pages (website) from scratch
- embed a weather service page (e.g. your Ecowitt.net dashboard) into your website
a selection of customizable weather websites fed with data from an Ecowitt station covering points 1 and 2 from the above list - 3. and 4. are for people with programming skills and experience only
website | example link | type | remarks | information |
---|---|---|---|---|
CumulusMX | http://meshka.eu/CumulusMX/ | ready-made | different themes (colours) available | https://cumuluswiki.org |
Meteotemplate | http://meshka.eu/meteo/template/ | construction kit | php plugins and “blocks” with icons, tables, graphs, maps can be placed in a 1-, 2- or 3-column setup | https://www.meteotemplate.com |
PWS-Dashboard | http://meshka.eu/pwsWD/ | widgetlike tiles can be placed in a 3×3, 3×4 and 4×4 and 5×5 setup (full and half-size tiles) including 1- multiple webcam photos | works with the Ecowitt customized server data | http://www.http://pwsdashboard.com/ |
Weather34 | http://meshka.eu/Weather34-Aurora-MKII/ | since 2024 Meteobridge only - there is a yearlong history of the template author moving in sort of a Saulus-Paulus transformation from a Davis only/Ecowitt never to an Ecowitt also perspective - it now comes as a free add-on to the Meteobridge software/hardware - earlier users (including the WiKi author) had been using it for years with some simple Ecowitt adaptations (and Meteobridge) in spite of the authors adamant rejection of support | works with Meteobridge (inbuilt option) or an information broker like FOSHKplugin - API definition for non-MB upload needed - will be published here / can be found at https://forum.meteohub.de (some search needed) | https://forum.meteohub.de/viewtopic.php?p=49249#p49249 |
weewx | http://meshka.eu/weewx/ | see weewx | https://www.weewx.com/docs | |
Cumulus Utils | http://meshka.eu/CUtils/ | Cumulus Utils (CUtils) is an application which comes with a ready-made portion and can be user enriched (or modified if you have the proper programming skills) - it works together with CumulusMX and needs CMX as data provider | http://meshka.eu/CUtils/ - click on “About” –> “CumulusUtils” menu item or go to https://www.cumuluswiki.org/a/Category:CumulusUtils |
3. you will need to know web programming (php, Java, Python etc.)
4. you will need to know that much programming that you know how to embed other web pages into your own webpage and keep them updated
in any case you will need your data to be sent/posted to your website, whether this website is located locally (on your NAS, on a RaspberryPi, …) or on a server in the internet provided by a web hosting provider.
for a general overview see Data Flow
Ways how to do this are:
- have your console do this (use the customized server option)
- have a data logging program do this (e.g. CumulusMX, Meteobridge, weewx, …)
- have an information broker do this (e.g. FOSHKplug, a self- or web-hosted MQTT broker, …)
- do it yourself (send data e.g. via (S)FTP, http requests etc.)
————————————————————————————————————————————————————————————————-
can I show an extra temperature/humidity sensor as the outdoor temperature/humidity sensor ?
on your console display, your dashboard on ecowitt.net, in the Ecowitt or WS View Plus app: NO
Background:
with respect to the outdoor temperature/humidity (T&H) the Ecowitt ecosystem is governed by the “Highlander Principle” - there can only be one. Which one is described in the Sensor Hierarchy
If you (want to) display your weather data on your own website, e.g. using a ready-made or customizable template, this is usually done by special applications/programs which are often at the same time data logging and archiving programs (e.g. CumulusMX, Meteobridge, weewx, HomeAssistant, FOSHKplugin), you can re-assign any other sensor values to the Outdoor T&H display.
With the proper programming skills you can also do this yourself, be it locally or on the website by using scripts or self-written programs with PHP, Java, Python ….
The same (Highlander) principle applies to weather observations like rain, wind, solar (see also sensor hierarchy, link above).
——————————————————————————————————————————————————————————————
why do I see sometimes very high solar peaks ? - is my sensor broken ?
Sometimes one can observe very high peaks in solar readings which are much higher than the theoretical maximum of solar irradiation/irradiance (sometimes also called insolation) at that time of the year in your geographical latitude.
example at 49° N latitude - 21-Apr-2024
(the bell shaped yellow curve is the theoretical maximum, the orange peaks are the actual readings, UV index is depicted blue)
There are two main reasons for this effect:
1. nano water droplets are on top of your solar sensor/light sensor can act as a magnifying lense
(after rainfall or due to dew)
2. the so-called cloud-edge effect* and cloud-lensing
*) the real-life phenomenon is sometimes also referred to as “Edge-of-Cloud-Event”
especially in smaller clouds the distribution of water droplets is such that the bigger droplet clusters are closer to the edge than the smaller ones which are mainly located in the center. Therefore the edges of a cloud can reflect the solar irradiance and add to the energy which arrives on a cloud-free day at the surface of the solar sensor - or of a photovoltaic (PV) solar array. Light refraction can also occur due to frozen water molecules in the outer cloud areas. In fact the cloud-edge effect is well known in PV contexts. The electrical elements have to take such bursts into account to limit the electricity generated for e.g. the inverter not to be damaged.
This is noticed because the solar sensor of the Ecowitt outdoor arrays are light sensors rather than energy sensors. They do not only read the direct solar irradiance (as a Pyranometer would do) but the global irradiance composed of direct and indirect components of the sunlight photometrically.
A pyranometer would “suppress” (i.e. either not notice or eliminate) the cloud-edge effect.
————————————————————————————————————————————————————————————————
my WS90 (Wittboy) rain readings are horrible - can I switch them off ? or what can I do about it ?
NO, you cannot switch them off unless you want to disassemble the array and disconnect cables/wires.
However, you can calibrate the WS90 rainfall reasonably well using its five-tier calibration facility.
see How to calibrate the WS90 rainfall
————————————————————————————————————————————————————————————————
how do I know that my rain gauge (WS69, WH40) reads properly ? And how to handle possible issues ...
proper and regular maintenance is key - we recommend to check and clean your traditional rain gauge every six months or when you encounter suspicious readings
if you want to avoid wrong readings caused by cleaning activities which may make the measuring spoon tilt, disconnect the sensor from all consoles it may be registered to (inside WSV+ where applicable (consoles with local Ecowitt API), inside the HP25x0, HP350x console sensor ID page or make the console powerless (WS2320, WS2910) and remove the batteries. For a WH40 it will be enough just to remove the battery from the sensor during maintenance time.
- Check to see if any debris has fallen into the funnel and ended up in the spoon, such as leaves, bird droppings, etc.
If any debris has fallen into the rainfall funnel, please remove it; also algae, Sahara sand etc.
Also spiders and other insects consider a rain gauge to be their new home and can obstruct the rain gauge function.
The spiral which comes with a WH40 inserted in the funnel can reduce the effect of leaves.
This spiral is available as accessory for a WH40 (shop.ecowitt.com), but can also be used in the WS69 funnel - If there is no debris in the funnel, you can use a manual rain gauge, put it close (1 m, 3 ft) to the funnel of the sensor, and compare (in Europe TFA sell fit for purpose models, in the US/CDN Stratus is a well-respected brand)
- we do NOT recommend to look up nearby weather stations in the Ecowitt weather station map (or Weather Underground or Weather Cloud) as often proposed as rainfall can be a very inhomogeneous event - 50 m away from you it may not rain at all - for an order of magnitude check a service like “compare adjecent stations in a radius of 10, 20, 50, 100 km” as offered by AWEKAS (example: https://www.awekas.at/en/qualcheck.php?id=16544) could still be indicative - but the manual rain gauge method is the simplest and most accurate.
- you can test the counting function by the help of a syringe or measuring cup to let a small amount of water slowly drip directly into the tipping bucket, hear a slight ringing sound, see whether the rainfall counter in the console has increased by 0.2mmor 0.1mm (WS69 for 0.2 mm/0.3 mm, WH40 for 0.1 mm). Do not pour in water quickly, as it will cause the tipping bucket/spoon not to go back properly into the starting position and rainfall will not be measured - the water will just flow through. (here the rain gauge has to be connected to at least one console - to avoid wrong data at the weather sites [Ecowitt, WU, WC] interrupt your router/internet connection for the test period)
- You can also manually simulate rainfall and drop in a defined amount of the water slowly which you then collect and measure when dropping out from the rain gauge (be aware that some water will be retained inside the mechanism).
You can use different amounts to simulate different rainfall strength. This simulation should be done with the rain gauge fully assembled: pour the water into the funnel, collect the water from under the funnel and cross-check against the console readings.
————————————————————————————————————————————————————————————————
Feels Like, Wind Chill, Heat Index, Apparent Temperature - which definitions used by Ecowitt
quote from Ecowitt:
Feels like temperature reading is defined according to NoAA’s definition, it is American Standard. We combined Heat index, Windchill into one: Feels like. You may find the definition here: https://www.ecowitt.com/shop/forum/forumDetails/242
Apparent Temperature is a newly added temperature asked by the Australian. They have a different algorithm. We followed their definition. https://www.ecowitt.com/shop/forum/forumDetails/574
So we allow user from Australia to select “apparent temperature” to be displayed under the feels like.
————————————————————————————————————————————————————————————————
how to send data to weather services like Ecowitt, Wunderground, WeatherCloud, WOW and others
Each Ecowitt console can post your weather data to ecowitt.net, wunderground.com, weathercloud.net and wow.metoffice.gov.uk, provided you have activated that option and entered the necessary credentials - these sites accept your data for free after you have registered with them and set up an account.
a list and comparision of different weather service providers including ecowitt.net, wunderground, WeatherCloud and WOW created by wxforum.net user @olicat is available here: Weather Services
There are many more Weather Services available in the internet where you may want to send your weather data to for free, but you will also give away the control over these data - as a compensation for offering the display and storage “for free” they will use/process/sell your data - it's part of their Terms and Conditions - and their business plan.
There are also paid plans where the same Terms and conditions apply. As a rule you can store you data longer, can post in shorter intervals and use some other services they provide if you choose a paid plan.
As far as we are aware, Ecowitt do not use or sell customer weather data, but the retention time and resolution of the data stored for free also has certain conditions or restrictions you should be aware of (see link).
These other “free” weather sites can be divided into two groups
1. websites where you can send your data there using the custom server capability of your Ecowitt console choosing Wunderground protocol for the data transfer.
examples see above link to custom server section
2. websites where you have to modify your console data before being able to post them.
(e.g. windy.com, CWOP …)
Some applications (e.g. FOSHKplugin, CumulusMX, Meteobridge, weewx …) offer ready-made posting strings which you can use along with these applications
(see also the sections for these applications here in the WiKi)
————————————————————————————————————————————————————————————————
are historical data saved by my gateway/console ?
The HP25x0 and HP350x consoles store data internally - and on a microSD card when plugged in. The microSD card can only be manually accessed i.e. taken out copied to a omputer and processed there. At the same time these consoles keep all time records for the classical sensors (wind, rain, T/RH indoor, T/RH outdoor, dewpoint, pressure, solar) on a separate page of their display. These data will survive a power-cycling but not a factory reset. You can also reset the records inside the console. More details see HP25x0 consoles and the console manuals. For data export see HP25x0 data export.
The new GW3000 and WS6210 consoles have a microSD card which can be accessed and data downloaded via the local network. The same applies to the Ambient Weather Network Hub 2.0 (new revision; “IP3”)
The WS2320E can record 3,600 records before the oldest is overwritten. It is provided with a Windows software (WeatherSmartIP, WeatherSmartWiFi) which can retrieve and save these data in a MS Access database on the PC. The interface software also allows for graphical and table-based reporting (see WS2320
When activated in the console, 5-minute based historical data of all registered sensors are sent and diplayed and stored for 90 days on ecoitt.net (see ecowitt.net dashboard). For retention times and archiving intervals see Retention time and Intervals.
For a (also internet independent) long time archiving of your weather station data we recommend one of the data logger programs.
————————————————————————————————————————————————————————————————
do the consoles/gateways store records (min/max values) ?
yes and no
The HP25x0 and HP350x consoles store alltime records which can be display on their “min/max” page.
The WS2320 console displays daily (on the current day only) and alltime records for each sensor field on the console display. The values will cycle in the two bottom lines of the diplay. Alltime records are also shown in the PC interface (see WS2320).
The WN19x0, WN182x, WN2810, WS3800, WS3900 consoles display the min/max values of the current day. They will be reset at midnight. With the WN2810 console you can choose if you want a midnight reset or alltime values.
On the ecowitt.net dashboard the min/max values of the current day are shown in the tile view and in the chart view (graphics). They are reset at midnight.
For historical data they will also be shown in the chart view. In the table view min/max values are not explicitly shown.
For a continuous follow up of daily records (min/max values) we recommend to use one of the data logging programs.
————————————————————————————————————————————————————————————————
what's the difference between the WSView Plus app and the Ecowitt app ?
in the early time of Fine Offset weather stations there was only one app to pair or to configure a console. It's history goes from WS Tools –> WS View –> WS View Plus. In the course of history the app became more and more powerful and functional and today WS View Plus is the most recent.
Once the ecowitt.net website for archiving and using user data was created, along with it a new app appeared by the name Ecowitt app which in the beginning was just the implementation of the ecowitt.net web browser dashboard in an app for for mobile devices on Android or iOS. Over time it also gained more functionality, but the features and use cases of the Ecowitt app and WS View Plus are not the same.
Simply speaking:
the focus of the Ecowitt app is the internet and the ecowitt.net website - with local options,
whereas
the focus of the WS View Plus app lies on the local network - with internet options.
the below table will reveal the details - and differences
feature | WS View Plus app | Ecowitt app | remarks |
---|---|---|---|
needs an internet connection | no | yes | for the EW app the login into the ecowitt.net user account is required |
can pair the console/gateway with the local router | yes | yes | in the local network only EW app needs internet connection to work |
can show the WU dashboard | yes | no | WSV+: internet connection required |
can show the EW dashboard(s) | yes | yes | internet connection for both apps required |
can show realtime data | yes | no | WSV+: only with consoles/gateways with the local Ecowitt API |
console/gateway configuration | yes | yes | inside the same local network; EW app additionally needs internet |
local IoT device management | yes | yes | EW app needs additionally internet access, WSV+ manual option only* |
full IoT device management | no * | yes | EW app needs internet access |
*) in the absence of an internet connection only the WSV+ app can operate the IoT devices locally (manual mode only - July 2024) - scheduled and smart plans can only be created by the Ecowitt app (WSV+ is planned to be able to do so too in the future)
————————————————————————————————————————————————————————————————
how to find the installed firmware version of the WS85 or WS90 ?
how to find the installed firmware version of the WS85 or WS90 ?
————————————————————————————————————————————————————————————————-
how to connect my gateway using its LAN interface (e.g. GW2000, GW3000 ...)
how to connect my gateway using its LAN interface (e.g. GW2000, GW3000 ...)
————————————————————————————————————————————————————————————————-
how to connect sensors to multiple gateways or channels using their sensor ID
how to connect sensors to multiple gateways or channels using their sensor ID
————————————————————————————————————————————————————————————————-
what different types of temperature sensors exist and how can they be used and how many of them
what different types of temperature sensors exist and how can they be used and how many of them
————————————————————————————————————————————————————————————————-
can I remove the metal mesh at the bottom of the wind reading section of my WS80/WS85/WS90 ?
can I remove the metal mesh at the bottom of the wind reading section of my WS80/WS85/WS90 ?
————————————————————————————————————————————————————————————————-
How many Megabytes does one post of a WS6210 per minute generate per month ?
How many Megabytes does one post of a WS6210 per minute generate per month ?
————————————————————————————————————————————————————————————————-
How can I see that the external power supply works with my WS80/WS90 ?
How can I see that the external power supply works with ?my WS80/WS90 ?
————————————————————————————————————————————————————————————————-
can I add missing data or delete wrong data at/from ecowitt.net ?
can I add missing data or delete wrong data at/from ecowitt.net ?
——————————————————————————————————————————————————————————————————-
how do I post data to Wunderground with my Ambient console ?
how do I post data to Wunderground with my Ambient console ?
——————————————————————————————————————————————————————————————————-
23. Reviews
————————————————————————————————————————————————————————————————-