Topic: MUST READ - Fine Offset Clone Models,sensor compatibility etc -discussion thread

[Gyvate]

Ecowitt added the WN30 multi-channel waterproof temperature sensor with external probe to their portfolio.
It shares the max number of channels with the WH31 multi-channel T/H sensor family. Now WH31, WH31-EP and WN30.
 
The 433 MHz version is on stock - 868 MHz and 915 MHz on request - 4-5 weeks production delay after order. Price 17 USD.
It was already sold for a couple of month (today 30-Apr-2021) by resellers (Froggit DP30, 868 MHz, 25 EUR and Ambient WH31P, 915 MHz, 25 USD).

It's a temperature only sensor (humidity under water doesn't make much sense; maybe it does if used in a freezer, but this is not the targeted use scenario),
therefore on the ecowitt.com page listed under Thermometers.

WN30 now also added to the compatibility matrix.

[davidefa]

Is there a 'complete' list of fields used in the custom uploads? ( an extension of what Oliver asked a few post ago )
I'm particularly interested in the fields uploaded by pm sensors (WH41, WH43, WH45), leaf wettness ( WH35), soil temperature (WN34).
Another question, do the new WN30 report temperature as WH31 do?

[Gyvate]

The Custom Server uploaded sensor values (Ecowitt protocol) are the same which are uploaded to ecowitt.net (i.e. all what is uploaded from your sensor "fleet" is what you see on the ecowitt.net interface - sensor values and battery status of the sensors you have).
It also depends on who does the upload - different consoles have their own sometimes limited set of sensors and sensor related data.
As for the GW1000/WH2650 console, there is a field map for the weather application software weewx which shows all available fields for sensor values (provided the respective sensor is active) of the GW1000 console known today.
https://github.com/gjr80/weewx-gw1000/wiki/Field-map
I speculate that the WN34S are the first set of eight sensors and the WN34L the second set of eight sensors of the 16 soil temperature sensors (S=soil, L=liquid).
Even though the weewx field map shows what the GW1000 provides when being polled, it should be the same content as what is pushed via the custom server functionality.
The sorting of this field map is weewx name ascending by character (while the sorting of the customer server string is different - see below).
Probably the HP2551 console sends the same amount data. GW1000/WH2650 and HP2551 cover the whole sensor portfolio of Ecowitt.

For my sensor "fleet" (see signature) the custom server posting of my GW1000 looks like below:
(s: string variable, #=field length => s:4 = string with field length 4; sequence is: field name, field content, definition is: field length, field value)
e.g. the field name station type is 11 characters long and the field content is "stationname";  its corresponding value is 14 characters long and the field content is "GW1000A_V1.6.6"

Code: [Select]

a:74:
{s:11:"stationtype";
s:14:"GW1000A_V1.6.6";
s:7:"dateutc";
s:19:"2021-05-01 22:03:14";
s:7:"tempinf";
s:4:"71.4";
s:10:"humidityin";
s:2:"39";
s:10:"baromrelin";
s:6:"29.940";
s:10:"baromabsin";
s:6:"28.907";
s:5:"tempf";
s:4:"49.5";
s:8:"humidity";
s:2:"51";
s:7:"winddir";
s:3:"180";
s:12:"windspeedmph";
s:4:"0.00";
s:11:"windgustmph";
s:4:"1.12";
s:12:"maxdailygust";
s:4:"1.12";
s:14:"solarradiation";
s:4:"0.00";
s:2:"uv";
s:1:"0";
s:10:"rainratein";
s:5:"0.000";
s:11:"eventrainin";
s:5:"0.000";
s:12:"hourlyrainin";
s:5:"0.000";
s:11:"dailyrainin";
s:5:"0.000";
s:12:"weeklyrainin";
s:5:"0.000";
s:13:"monthlyrainin";
s:5:"0.000";
s:12:"yearlyrainin";
s:6:"15.118";
s:11:"totalrainin";
s:6:"15.118";
s:6:"temp1f";
s:5:"49.28";
s:9:"humidity1";
s:2:"51";
s:6:"temp2f";
s:5:"50.90";
s:9:"humidity2";
s:2:"56";
s:6:"temp3f";
s:5:"49.10";
s:9:"humidity3";
s:2:"51";
s:6:"temp4f";
s:5:"50.00";
s:9:"humidity4";
s:2:"50";
s:6:"temp5f";
s:6:"-11.38";
s:6:"temp6f";
s:5:"50.18";
s:9:"humidity6";
s:2:"48";
s:6:"temp7f";
s:5:"43.88";
s:9:"humidity7";
s:2:"51";
s:13:"soilmoisture1";
s:2:"42";
s:13:"soilmoisture2";
s:2:"72";
s:13:"soilmoisture4";
s:2:"64";
s:13:"soilmoisture5";
s:2:"41";
s:8:"pm25_ch1";
s:4:"11.0";
s:16:"pm25_avg_24h_ch1";
s:4:"12.4";s:8:"pm25_ch2";
s:4:"15.0";
s:16:"pm25_avg_24h_ch2";
s:4:"13.2";
s:6:"tf_co2";
s:4:"70.7";
s:8:"humi_co2";
s:2:"41";
s:8:"pm25_co2";
s:3:"7.4";
s:12:"pm25_24h_co2";
s:3:"7.5";
s:8:"pm10_co2";
s:3:"7.9";
s:12:"pm10_24h_co2"
;s:3:"7.9";
s:3:"co2";
s:3:"939";
s:7:"co2_24h";
s:3:"863";
s:14:"lightning_time";
s:10:"1619689115";
s:13:"lightning_num";
s:1:"0";
s:9:"lightning";
s:2:"14";
s:8:"wh65batt";
s:1:"0";
s:8:"wh80batt";
s:4:"3.04";
s:8:"wh26batt";
s:1:"0";
s:5:"batt1";
s:1:"0";
s:5:"batt2";
s:1:"0";
s:5:"batt3";
s:1:"0";
s:5:"batt4";
s:1:"0";
s:5:"batt5";
s:1:"0";
s:5:"batt6";
s:1:"0";
s:5:"batt7";
s:1:"0";
s:9:"soilbatt1";
s:3:"1.6";
s:9:"soilbatt2";
s:3:"1.4";
s:9:"soilbatt4";
s:3:"1.6";
s:9:"soilbatt5";
s:3:"1.4";
s:9:"pm25batt1";
s:1:"5";
s:9:"pm25batt2";
s:1:"5";
s:8:"wh57batt";
s:1:"4";
s:8:"co2_batt";
s:1:"6";
s:4:"freq";
s:4:"868M";
s:5:"model";
s:10:"GW1000_Pro";}


[davidefa]

Thank you for the prompt reply.
1) your sensor report is super useful ( as it includes lots of sensors )
2) the weewx reference is super complete... but don't think is super 'useful' ( but certainly a good starting point ).
What I mean is that the weewx second column ( the gw1000 field name column ) reports several 'well-known' field name differently, ex:
dateutc reported as datetime
baromabsin reported absbarometer
pm25_ch1 reported as pm251
...
Maybe because these are the fields retrieved by the weewx driver via the api... and the api field names are different from the 'ecowitt protocol' field names ( only an hypothesis, but, if this is true, not a good idea on the ecowitt part... at least to let my life easier ; - )

P.S.
Checked also the weewx interceptor driver... but is has a very limited sensor definition

[Gyvate]

...
Maybe because these are the fields retrieved by the weewx driver via the api... and the api field names are different from the 'ecowitt protocol' field names ( only an hypothesis, but, if this is true, not a good idea on the ecowitt part... at least to let my life easier ; - )

correct - that's the interface description (or record definition in some programming language jargon) into which the GW1000 data are loaded before further processing by weewx

P.S.
Checked also the weewx interceptor driver... but is has a very limited sensor definition

the interceptor driver reads what is sent by the console via the custom server option - if you want to receive the console data via the interceptor driver, you will have to define a sensor_map in weewx if you have more than the "classical" sensors you want to process in weewx;
for the GW1000 the weewx GW1000 API driver is much more elegant, encompasses all sensors the GW10000 can receive and process and is less problematic (and your console custom server option remains free for other purposes you might have).
If you have, e.g. only a HP2551, WS2320E or HP350x console, and want to process their data in weewx, you are stuck with the interceptor driver (unless you get yourself an extra GW1000).

[davidefa]

I need the list of fields uploaded by the custom ecowitt protocol to update the ecowitt plugin of meteotemplate ( plugin by raffaello dimartino ).
This is the partial list so far ( # is the sensor number, replace with 1-4, 1-8, 1-16?? ):

Code: [Select]

ecowitt field      meteotemplate field
-------------      --------------------
freq
model
stationtype
PASSKEY
runtime             // only ws1900

dateutc
// T/H/P
tempinf             TIN
humidityin          HIN
baromrelin          P
baromabsin
tempf               T
humidity            H
feelslikef
windChillf
dewptf
heatindexf
// wind
winddir             B
windspeedmph        W
windgustmph         G
maxdailygust
// light
solarradiation      S
uv                  UV
// rain
rainratein          RR
eventrainin
hourlyrainin
dailyrainin         R
weeklyrainin
monthlyrainin
yearlyrainin
totalrainin
// wh31-WN30
temp#f              T#
humidity#           H#
// WN34 soil/water temperature
tf__ch#             TS#
// wn35 leaf wettness
leafwettness_ch#    LW#
//wh41-43
pm25_ch#            PP#
pm25_avg_24h_ch#
// wh45
tf_co2
humi_co2
pm25_co2
pm25_24h_co2
pm10_co2
pm10_24h_co2
co2                CO2_1
co2_24h
// wh51
soilmoisture#      SM#
// wh55
leak_ch#
// wh57
lightning_time     LT
lightning_num      L
lightning          LD
// battery status
wh25batt           WH25BAT ( 0 = OK; 1 = LOW )
wh26batt           WH26BAT ( 0 = OK; 1 = LOW )
wh40batt           RBAT NOTE: wh40 does not report battery level ( or only newer ones report battery level ?! )
wh65batt           WH65BAT ( 0 = OK; 1 = LOW )
wh68batt           WH68BAT ( value: 1.5V battery voltage )
wh80batt           WH80BAT ( value: 3V battery voltage )
ws1900batt        WS1900BAT ( value 3V battery voltage )
// wh31-WN30
batt#              T#BAT   ( 0 = OK; 1 = LOW )
// wn34
tf_batt#           TS#BAT  ( where # = 1..8; value: 1.5V battery voltage )
// wn35
leaf_batt#         LW#BAT  ( where # = 1..8; value: 1.5V battery voltage )
// wh41-43
pm25batt#          PP#BAT  ( where # = 1..4; value: 0-5; 0-1 = LOW )
// wh45
co2_batt           CO2_1BAT  ( value: 0-7; 0-1 = LOW )
// wh51
soilbatt#          SM#BAT  ( where # = 1..8; value: 1.5V battery voltage )
// wh55
leakbatt#
wh57batt           LBAT    ( value: 0-5; 0-1 = LOW )


[gjr80]

...
Maybe because these are the fields retrieved by the weewx driver via the api... and the api field names are different from the 'ecowitt protocol' field names ( only an hypothesis, but, if this is true, not a good idea on the ecowitt part... at least to let my life easier ; - )

correct - that's the interface description (or record definition in some programming language jargon) into which the GW1000 data are loaded before further processing by weewx

Just to be clear, the GW1000 API does not define any field names; rather it specifies what data is available via what API call and how to decode it. The GW1000 driver field names are used internally by the GW1000 driver and deliberately bear no resemblance to those fields used in the Ecowitt upload protocol. The only time these internal driver fields will be visible from outside the driver will be if the field mapping (ie the map from internal driver fields to WeeWX loop packet fields) is such that the internal field name is passed on. This does occur for a number of fields under the driver default field mapping. Again this was a deliberate decision. I don't see any of this as a fault either by Ecowitt or the GW1000 driver.

At best the GW1000 driver default field map gives an indication of what data may be available via the Ecowitt upload protocol but it provides little else regards the Ecowitt upload protocol.

Gary

[Gyvate]

...
Maybe because these are the fields retrieved by the weewx driver via the api... and the api field names are different from the 'ecowitt protocol' field names ( only an hypothesis, but, if this is true, not a good idea on the ecowitt part... at least to let my life easier ; - )

correct - that's the interface description (or record definition in some programming language jargon) into which the GW1000 data are loaded before further processing by weewx

Just to be clear, the GW1000 API does not define any field names; rather it specifies what data is available via what API call and how to decode it. The GW1000 driver field names are used internally by the GW1000 driver and deliberately bear no resemblance to those fields used in the Ecowitt upload protocol. The only time these internal driver fields will be visible from outside the driver will be if the field mapping (ie the map from internal driver fields to WeeWX loop packet fields) is such that the internal field name is passed on. This does occur for a number of fields under the driver default field mapping. Again this was a deliberate decision. I don't see any of this as a fault either by Ecowitt or the GW1000 driver.

At best the GW1000 driver default field map gives an indication of what data may be available via the Ecowitt upload protocol but it provides little else regards the Ecowitt upload protocol.

Gary

@Gary: you said in other words - probably more clearly - what I wanted to say.

davidefa wants (as I read it) to update an interface for Meteotemplate created by one of our community members based on the ecowitt protocol by the help of which Ecowitt sensors can be displayed on the Meteotemplate "skin", i.e. in a self-built block or plugin in the MT terminology - so he needs to know what would all be sent by the GW1000 or a HP2551 console if we were in possession of all available Ecowitt sensors.
Here the weewx GW1000 field map would give an indication what fields that would all (functionally) be.
I personally think that his "complaint" is probably due to a 1:1 translation from his Italian mother tongue into English , so it's not a complaint but meant to be a (fair) statement.

For the WN34 and WH35 names in the ecowitt protocol he will have to wait until these sensors become available in the market and someone from our community starts using them.
For all the others he got an example for the names from me (from my sensors posted by a GW1000 ) and can derive the number from the weewx interface (or by due diligence on the ecowitt.com website going through all available sensors) and through "my" table/matrix here in this forum.

You have just made a nice and very useful table.
By the way - in the weewx github wiki the GW1000 API driver is until now NOT mentioned in the overview - only the interceptor driver can be found described under the "Get data from a GW1000" link
(https://github.com/weewx/weewx/wiki)
in my opinion there should be either an additional link for the GW1000 API driver on the main page or as a second option described at the link target page. Your splendid https://github.com/gjr80/weewx-gw1000/wiki seems to fall through the grid (or I am too blind to find the respective entry ...)
Many GW1000 users start unnecessarily using the interceptor driver for a GW1000 due to that link where there is something much better available.

[olicat]

Hi!

For the WN34 and WH35 names in the ecowitt protocol he will have to wait until these sensors become available in the market and someone from our community starts using them.

This is the current status from the firmware point of view. However, that may change before the sensors are released:

WN34:
tf_battN (where N = 1..8; output probably voltage)
tf_chN (where N = 1..8 )

WH35:
leaf_battN (where N = 1..8; output probably voltage)
leafwetness_chN (where N = 1..8 )

The batt values are still to be regarded as uncertain. It can also be that these are then output in levels (0-5).
However, I'm relatively sure about the actual values and names. This is how they are stored in the firmware. (And this is how it is implemented in FOSHKplugin.)

Regards, Oliver

[davidefa]

Thank you Oliver, I did check your plugin v0.07... but not the newly released v0.08 : - (

[Gyvate]

Froggit have announced their DP250, the Froggit version of the Ecowitt WH45 5-in-1 indoor air quality sensor.
https://www.froggit.de/product_info.php?language=en&info=p483_dp250-5-in-1-co2-pm2-5-pm10-temperatur-luftfeuchte-innenraum-luftqualitaets-funksensor--bald-verfuegbar-.html
Updated the matrix accordingly. It's still marked as "available soon" on their web site (10-May-2021) which indicates that they are waiting for a shipment from Fine Offset.

[Gyvate]

The question has come up if the outdoor sensor array which comes with older FineOffset stations like the WH5300 is compatible with a GW1000 or whether it uses the same technology as a WN67 (light weight outdoor sensor array which will come with the WN1900). They are not compatible.
We added corresponding information in footnote 23 regarding the WN67 sensor array.

[Gyvate]

Ecowitt released today, 03-Jun-2021, version 1.7.3 of its HP2551 console firmware.
They fixed some bugs and improved especially German translations - but also introduced a rather annoying bug:
the text for the Indoor T/H sensor is now "WH32" instead of "Indoor" on the main display - hopefully to be fixed soon.
Reported to Ecowitt.
EDIT: one can fix it oneself - once one knows how - quite a hidden and not very logical place ... - see next post

[Gyvate]

I have to revise part of my earlier posting.
I have meanwhile learnt that my observation - that the changed naming of the indoor temperature/humidity sensor of the HP2551 - is not a bug but reveals a feature. The firmware update purged the former name and replaced it by the "WH32" text.
If you don't like this text (I didn't as it was wrong and I preferred the old "Indoor"), you wonder how/where to change it.
I did a long search through the console and the manual - and only got successful by the hint of a forum member.

The WH32B indoor temperature/humidity/pressure sensor is considered to be an OPTIONAL sensor, which I find strange for a console which doesn't have an inbuilt T/H/P sensor and its part of the basic package.

Once you know that you can also find it on the "Optional Sensor Display Mode" page of the console (press 4 x ▼) and also change the sensor's display name on the main display ...
But it's not documented, at least not clearly. Who would expected a basic T/H/P sensor to be an extra or optional sensor ...
And the example picture of the manual does NOT show the WH32B sensor even though it's part of the basic package (console, sensor array, T/H/P indoor sensor).
I will add this info to the console description as I guess I'm not the only one who gets somewhat lost here ...

[kheller2]

I'm new here and just wanted to say thank you for the great comparison chart and details notes on all the models.  Thank you!!!!!  It has made mixing my old system with my new one very easy. 

I understand it is only showing existing shipping products, but I do wish it had the WH24B, 25B, WS-1200 and WS-0900-IP (all the stuff from the WS-1200-IP system).   I was pleasantly surprised to see a WS-1900-CONSOLE pickup everything on my 24B and all my WH31* all over.  Granted, the wind gust/speed is half what it should be on the 1900, but then the 1900 isn't listed as being compatible with my old 24B (single vs dual pulse issue).

I know lots of people don't seem to have a fondness for the WH24B array, but it has served me well over the past 5 years (other than the silly humidity sensor always a bit off, which I promptly got a replacement 24B. .. Now I have two... These old 24Bs are great to tinker with and upgrade and mate with the GW1000.)

[Weather Spares]

Great thread.

I'm not sure if it has been mentioned before but the the mainly Meteobridge products (NANO etc) used in Davis stations are now able to collect data from the GW1000 gateway device for anyone using a mixed brand environment.

[Gyvate]

Great thread.

I'm not sure if it has been mentioned before but the the mainly Meteobridge products (NANO etc) used in Davis stations are now able to collect data from the GW1000 gateway device for anyone using a mixed brand environment.

The compatibility matrix has a special line for "application" software (weather software), where also Meteobridge is shown as usable with a GW1000/WH2650.
 [ You are not allowed to view attachments ]  
For Meteobridge this applies to all platforms: MB, MB NANO, MB Pro and MB on RPi

[mahi]

Gyvate: For your overview: Froggit now also sells the WH2650 WIFI + WH32B without the WH65 7-in-1 outdoor array (link). This is great if you want the WH2650 console but combine it with the WS68 for example.

I like the WH2650 over the GW1000 because it allows you to place the separate WH32B indoor sensor in an ideal location without requiring the console to be very nearby. The drawback is of course yet another sensor that takes batteries.

[Gyvate]

Gyvate: For your overview: Froggit now also sells the WH2650 WIFI + WH32B without the WH65 7-in-1 outdoor array ** (link). This is great if you want the WH2650 console but combine it with the WS68 for example.

I like the WH2650 over the GW1000 because it allows you to place the separate WH32B indoor sensor in an ideal location without requiring the console to be very nearby *. The drawback is of course yet another sensor that takes batteries.
Last year it was sold with the 7-in-1 outdoor array (as Steinberg Systems SBS-WS-600) for 65 EUR only  , then 85 EUR, now 99 EUR at expondo.de , but still with 3 years warranty (vs. Froggit: 1 year only)

*) yes, see my post at https://www.wxforum.net/index.php?topic=40970.0
It's definitely more flexible if you don't mind the shape (what some people do - design over functionality  )
As for the batteries - indoor they hold longer than 2 years, but you should replace them after two years to avoid leakage

**) yes, I know - you either get it from Fine Offset as WH2650 (+ WH32B) or (now, recently) from Froggit as WH2600 Pro without outdoor array - the Froggit price of 50 EUR is +/- the same as getting it from FineOffset/Ecowitt (42 USD + 19% VAT).
Last year it was sold with the 7-in-1 outdoor array (as Steinberg Systems SBS-WS-600) for 65 EUR only  then 85 EUR and now 99 EUR at expondo.de with a 3-year warranty (vs. 1 year with Froggit only).

[Gyvate]

added CumulusMX >= V12 (3141) as application software for (almost) all new FineOffset clone consoles.
CMX V12 can now use a console (or server, e.g. FOSHKplugin) which posts in Ecowitt protocol to a custom server (here: CMX) as either
- main station
or
- supplementary station to enrich an existing station by extra sensor data

As far as I know adding the Ambient protocol is still "under construction" but planned for a later version => a WH2902 or a WS-2000/WS-5000 console could then also connect to CMX via Ambient protocol and display basic + extra sensors.

Already now the Ambient stations could use their custom server options to connect to CMX via the WU protocol, also from V12 (build 3141) on, (WU protocol however only supports basic sensors, no extra sensors)

[Gyvate]

added the WN34L water temperature and WN34S soil temperature sensors (1-8) as released to the matrix
added the WN35 leaf wetness sensor (1-8) as released to the matrix
the WH31/WN30 family, the WN34 family and the WN35 sensors can have a maximum of 8 different sensors (realized via channels) each per console.
The WN30 water temperature with attached cabled probe is probably meant more for indoor use (aquariums, fish tanks or freezers) while the WN34L is definitely an outdoor sensor (pools etc.)

[G.Brown]

Hi Gyvate,  the Ecowitt.net site Battery condition log refers to a WH25 sensor and a WS65 sensor whereas in your 'Fine Offset (FOSHK) Weather Stations i.e. consoles, sensors and clones' thread they are referred to differently. Which one is correct? I'm trying to rename them so I know what they are.
Thanks again. Gordon.

[Gyvate]

Hi Gyvate,  the Ecowitt.net site Battery condition log refers to a WH25 sensor and a WS65 sensor whereas in your 'Fine Offset (FOSHK) Weather Stations i.e. consoles, sensors and clones' thread they are referred to differently. Which one is correct? I'm trying to rename them so I know what they are.
Thanks again. Gordon.

So who is correct ? Both ! 😛

In 2020 Ecowitt introduced a new acronym scheme which can also be found in the main thread.
https://www.wxforum.net/index.php?topic=40730.0  acronym scheme
Including the exception for WH65/WH69 [WS65/WS65] - the example is for the WH69/WS69 only though.

There is some legacy naming e.g. WH65 as this was built before they decided to streamline their sensor acronyms.
On ecowitt.net the WH65/WS65 is shown as WS65, whereas in the GW1000 API and in the api string sent with the
custom server option it still says WH65.
WS is more correct as the WH65 has a solar panel - and its battery status is in most locations (unless extreme conditions)
not very helpful as the battery is allmost never used. Mainly for the first startup.
The supercapacitor charged by the solar panel holds for 2+ days to keep the station running - only if it expires, the
batteries would be used. It needs very cold weather and very little solar radiation over a couple of days for such a situation to occur.
Maybe after some massive volcano eruption ...

[G.Brown]

thanks and WH25?

[Gyvate]

WH24 is the WH65 predecessor (the "boat") and the WH25 is the WH32B predecessor