WXforum.net
Weather Station Hardware => Ambient Weather and Ecowitt and other Fine Offset clones => Topic started by: mcrossley 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.
-
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)
-
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:
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) ?
-
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
-
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
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
{ "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
-
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 :!:
-
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!
-
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...
-
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
-
Odd though that the device has the values to send in the Ecowitt protocol, but they can't put them in the API response.
-
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
-
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).
-
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
-
Thanks Stuart, I'm not going mad then!
-
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)
-
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
-
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
-
Page 8 of the new document shows
#define ITEM_RAINDAY 0x10//Rain Day (mm) 2
#define ITEM_RAINWEEK 0x11//Rain Week (mm) 2
and on page 24 it shows
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
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