Author Topic: Ecowitt Local API - READ_RAIN (0x57)  (Read 1078 times)

0 Members and 1 Guest are viewing this topic.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Ecowitt Local API - READ_RAIN (0x57)
« on: February 22, 2023, 06:12:21 AM »
Anyone know what the 0x7B field is (single byte)?
It is not in the documentation I have - v1.6.4 - that jumps from 0x79 to 0x80

I already have the 0x7A field value from somewhere.
« Last Edit: February 23, 2023, 06:29:02 AM by mcrossley »
Mark

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #1 on: February 22, 2023, 10:09:08 AM »
afaik 0x7A - 0x7F are not documented as markers so far
can you give a hex dump example of 0x7B - meaning: is it a marker or does it happen to be some (spurious ?) value in the API response ?
all existing sensors and their readings are covered by the documented markers and no new sensors have been released.
But it could be one of new IoT devices in ß-test ... (IoT valve and IoT switch). Or the HP10 camera ...
But you would have to have one if you find its value in the API response - plus the firmware would need already to be adapted for them (what of course is possible)
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #2 on: February 22, 2023, 11:04:53 AM »
As it is in the response to the rain data command, I guess it will be rain related.  ;)

The value from my GW1000 is a single byte of zero - but I do not have a rain sensor.
Mark

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #3 on: February 22, 2023, 02:12:03 PM »
@Mark:
Have a look at https://www.wxforum.net/index.php?topic=40730.0 chapter 14
the API response to the 0x57 command is a real life response with a WH40 and a WS90 connected.
No 0x7B to be seen - only a 0x7A with a 02 one byte value before the checksum.
No idea what the firmware has put there.

By the way - do you get 0x03 and 0x04 (dew point and wind chill) and corresponding values in your API response for 0x27 (LIVEDATA) ?
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #4 on: February 22, 2023, 06:25:18 PM »
By the way - do you get 0x03 and 0x04 (dew point and wind chill) and corresponding values in your API response for 0x27 (LIVEDATA) ?

Nope never seen them, jumps from 01 to 06
Mark

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #5 on: February 23, 2023, 04:56:52 AM »
I've been watching this thread and just checked my livedata string from my GW1100 and it does not show keys 0x03 or 0x04 when accessed via a sockets call to the GW1100, however when doing the call to the GW1100 using HTTP I do see these keys. Which indicates to me that there is an issue here which Ecowitt needs to address.

The raw data split out by key value and data shows

Code: [Select]
ffff27005c Header
 01 00c5
 06 3b
 08 278b
 09 27b9
 02 0045
 07 5c
 0a 0034
 0b 0027
 0c 003d
 15 00016fe4
 16 0000
 17 00
 2a 0000
 4d 0037
 1a 0049
 22 59
 1b 00c7
 23 3b
 62 00000000
 61 63f14470
 60 1f
 19 005b
 0e 0000
 10 0004
 11 000c
 12 00000014
 13 000001b5
 0d 0006
 f1      CRC

and the live data call via http shows

Code: [Select]
{ "common_list": [
{ "id": "0x02", "val": "6.9", "unit": "C" },
{ "id": "0x07", "val": "92%" },
{ "id": "3", "val": "4.8", "unit": "C" },
{ "id": "0x05", "val": "6.9", "unit": "C" },
{ "id": "0x03", "val": "5.7", "unit": "C" },
{ "id": "0x04", "val": "4.8", "unit": "C" },
{ "id": "0x0B", "val": "6.71 mph" },
{ "id": "0x0C", "val": "9.84 mph" },
{ "id": "0x19", "val": "20.36 mph" },
{ "id": "0x15", "val": "57.16 W/m2" },
{ "id": "0x17", "val": "0" },
{ "id": "0x0A", "val": "57", "battery": "5" }
],
"rain": [
{ "id": "0x0D", "val": "0.6 mm" },
{ "id": "0x0E", "val": "0.0 mm/Hr" },
{ "id": "0x10", "val": "0.4 mm" },
{ "id": "0x11", "val": "1.2 mm" },
{ "id": "0x12", "val": "2.0 mm" },
{ "id": "0x13", "val": "43.7 mm", "battery": "0" }
],
"wh25": [
{ "intemp": "19.7", "unit": "C", "inhumi": "59%", "abs": "1012.2 hPa", "rel": "1016.8 hPa" }
],
"lightning": [
{ "distance": "19.2 mi", "timestamp": "02/18/2023 21:34:40", "count": "0", "battery": "5" }
],
"ch_pm25": [
{ "channel": "1", "PM25": "0.0", "PM25_RealAQI": "0", "PM25_24HAQI": "23", "battery": "4" }
],
"ch_aisle": [
{ "channel": "1", "name": "Outdoors", "battery": "0", "temp": "7.3", "unit": "C", "humidity": "89%" },
{ "channel": "2", "name": "Lounge", "battery": "0", "temp": "19.8", "unit": "C", "humidity": "59%" }
]
}

also there seems to be an issue with the above where one "id" value shows "3" as well as an "id" of "0x03".

Looks to me that the string returned from a socket call for command 27 (get live data) differed from the http call which makes no sense at all. Also I do not have a wh25 so have no idea what that represents, and I do not understand "ch-aisle"

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #6 on: February 23, 2023, 05:08:49 AM »
a) there is a new marker 0x7A which stands for rain priority (classical or piezo)- 1 byte; Ecowit have updated their document (V.1.6.7) but in Chinese only so far - I assume it will soon be published in English too.
0x7A is the only update

b) @Stuart
the question for 0x03 and 0x04 of the API response to the LIVEDATA request is with Ecowitt
waiting for their reply - I asked if this is a firmware bug  8-)

WH25 is the name of the WH32B (WH32 indoor) predecessor - and what you get is the data from a WH32B
see https://www.wxforum.net/index.php?topic=40730.0 footnote 22  :!:
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #7 on: February 23, 2023, 06:14:37 AM »
WH25 is the name of the WH32B (WH32 indoor) predecessor - and what you get is the data from a WH32B
see https://www.wxforum.net/index.php?topic=40730.0 footnote 22  :!:

But I don't have a WH32B either!

b) @Stuart
the question for 0x03 and 0x04 of the API response to the LIVEDATA request is with Ecowitt
waiting for their reply - I asked if this is a firmware bug  8-)

Thanks this is a GW1100 with the latest F/W btw.

Stuart

PS the more I look at the http information it makes no sense since it shows the pressure only as part of a sensor I do not have and should in my view be part of common!
« Last Edit: February 23, 2023, 06:21:52 AM by broadstairs »
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #8 on: February 23, 2023, 07:38:56 AM »
regarding dewpoint and wind chill in the local API response - the Ecowitt reply is:
"With this API, the dew point and wind chill is not provided by the device side. You need to calculate in the application side. "

@broadstairs
regarding WH25: this may still be the inbuilt indoor sensor of the GW1100...
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #9 on: February 23, 2023, 07:54:37 AM »
regarding dewpoint and wind chill in the local API response - the Ecowitt reply is:
"With this API, the dew point and wind chill is not provided by the device side. You need to calculate in the application side. "

@broadstairs
regarding WH25: this may still be the inbuilt indoor sensor of the GW1100...

Understand the first point. However the wh25 is completely nonsensical in the http protocol, yes it maybe the gateway sensors but I've that is the case it should say so. The GW1100 also gives ridiculous battery information for the non-existent wh25 in the api get battery data command.

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #10 on: February 23, 2023, 08:28:26 AM »
Odd though that the device has the values to send in the Ecowitt protocol, but they can't put them in the API response.
Mark

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #11 on: February 23, 2023, 01:26:45 PM »
Odd though that the device has the values to send in the Ecowitt protocol, but they can't put them in the API response.
still investigating - but maybe these are two different pieces of software and the local API response is picking up the data at a stage when dew point and wind chill are not yet available/calculated ...
probably the WS View Plus app doesn't read the dew point and wind chill as live data but calculates the values on the fly ...
let's see - maybe Ecowitt can/want to shed more light on the topic
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #12 on: February 24, 2023, 04:39:19 PM »
Ecowitt's reply regarding the dew point and wind chill is succinct and clear:
the code for providing dew point and wind chill in the firmware for the local API response doesn't exist (period, full stop).
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #13 on: February 26, 2023, 06:47:37 AM »
Anyone know what the 0x7B field is (single byte)?
It is not in the documentation I have - v1.6.4 - that jumps from 0x79 to 0x80

I already have the 0x7A field value from somewhere.

Mark to get back to your original question I have now been testing the 0x57 command and yes when I run it against my GW1000 it comes up with an 0x7b but my GW1100 does not issue that key in its response to this command. I do not have the WS90 so am only expecting valid data for the WH40 but even that is not correct in some cases.

I have other issues surrounding this command and the responses when no WS90 is configured and I intend to discuss it with Ecowitt. It has been suggested to me that this command might only be intended for use when a WS90 is configured but nowhere in the current documentation (in English - there is some Chinese interspersed in the text!) does it say that!

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1132
    • Wilmslow Astro
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #14 on: February 26, 2023, 02:14:24 PM »
Thanks Stuart, I'm not going mad then!
Mark

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #15 on: February 27, 2023, 03:36:02 AM »
it look as if the firmware for GW1100 and the GW1000 have different code ...
GW1000 returns also the status of radiation compensation what the GW1100 (and probably the GW2000 either) do not provide.

as per Ecowitt in the to be published V. 1.6.8 of the local API document there will be now two new keys/markers in the 0x7n range:
0x7A/1 byte   (rain gauge preference) 1=classical, 2=piezo
0x7B//1Byte ( Radiation compensation)

I guess that explains the 0x7B in GW1000s
a firmware update for GW1100/GW2000 to be expected

affected are the commands 0x57  (READ_RIN) and 0x58 (WRITE_RAIN)
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #16 on: February 27, 2023, 03:42:23 AM »
I've had a reply from Ecowitt confirming just this. However there is still the issue of using the same key/id values with differing lengths which makes no sense. I'm guessing that new document is available now so I'll check that first and then see what might still be needed.

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline Gyvate

  • Forecaster
  • *****
  • Posts: 3298
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #17 on: February 27, 2023, 03:59:11 AM »
I cannot see any difference in either the field definition or in the API responses for LIVEDATA or READ_RAIN for the classical rain gauge (0x0D-0x14) - always rain week through total are 4 bytes, the others two bytes
WS2350 1.6.7, GW1000(3) 1.7.7,WH2650 WiFi (2) 1.7.7 (test/backup), GW1100 2.3.1, GW2000(3) 3.1.1, HP2551 1.9.5,5.1.5;HP3500 1.7.2,WS3800 1.2.8, WN1910 1.2.3,WN1980 1.2.3;
Ecowitt WS90(2)1.3.5/1.4.0, WS80(2)1.2.5, WS68, WS69, WH40, WH31, WH31-EP, WN30, WN34L, WN35, WH32, WH32-EP, WH32B, WH57 [Lightning], WH41 [PM2.5], WH51, WH45, WH55
MeteobridgePro(2)[test,prod] 5.8 Mar 01 2024, 15185 - Blake-Larsen Sun Recorder - RPi4/weewx 4.8.0/4.10.2/CumulusMX 3283/Meteobridge RPi4B-2GB(3169)
Barani Meteoshield Pro, MetSpec Rad02 - Ecowitt 5763,34418;WU ISAARB3(WH4000SE),ISAARB22(HP2553), http://meshka.eu

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 853
Re: Ecowitt Local API - READ_RAIN (0x57)
« Reply #18 on: February 27, 2023, 04:26:22 AM »
Page 8 of the new document shows

Code: [Select]
#define ITEM_RAINDAY 0x10//Rain Day (mm) 2
#define ITEM_RAINWEEK 0x11//Rain Week (mm) 2

and on page 24 it shows

Code: [Select]
ITEM_RAINDAY      4
ITEM_RAINWEEK    4

and in response to the 0x57 command the output uses the same key/id numbers but with different lengths of 4 so you cannot rely on using the key/id number and length to step through the output.

Output from a GW1000 in response to an 0x57 command is

Code: [Select]
ffff5700290e00001000000000110000000c120000001413000014ef0d00000f0064880000007a017b01f6  GW1000

ffff570029  header
0e 0000      rain rate
10 00000000  daily rain         this key/id value elsewhere has a defined length of 2
11 0000000c  weekly rain        this key/id value elsewhere has a defined length of 2
12 00000014  monthly rain
13 000014ef  yearly rain (this is an incorrect value)
0d 0000      rain event
0f 0064      rain gain     renamed in the new document to this
88000000    piezo rain reset time
7a01       
7b01       
f6          CRC

If key/id values are supposed to be unique then the way the 0x57 command presents data is at least illogical if not plain wrong.

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.