Topic: GW1100 - GW1000 - GW2000 Windows Store Application Dashboard (TCP Protocol)

[Rover1822]

I've always considered the release of the API as a nice to have. Initially, it was very hard to get access to it and was considered closed , and members of this group lobbied hard to have it opened up . I really don't believe the availability of the API had anything to do with the product development in their thought process for the product. I mean it is primarily a cheap way to have a weather station.

No argument the API is confusing, and has occasional changes (a no no for those that use it).  For what I use, I just use the custom server option and parse HTTP requests. Not the best thing, but all I need. I can understand your frustration.

Edit: We were ecstatic with even the custom server option when that came about. It allowed a lot of other integrations without being stuck with the standard weather services. I mean most consumer level stuff, don't give you that. I get it is push only, but we didn't have anything at that point. 

[cheeroip]

I've always considered the release of the API as a nice to have. Initially, it was very hard to get access to it and was considered closed , and members of this group lobbied hard to have it opened up . I really don't believe the availability of the API had anything to do with the product development in their thought process for the product. I mean it is primarily a cheap way to have a weather station.

I always think about an API from the producer point of view.
Why they release it; what is their goal? How many resources are they going to put into it, is it part of a wide strategy or is it something that one department / side contractor just do on their own for their own reasons?

From my point of view having a local API would be a no brainer for every kind of IOT device.
I'm well aware of how scared are companies to share their stuff but it's really just ignorance and short-sightedness 99% of the time.
It's not that they planning carefully ahead how one decision would effect their strategy.
I feel that all these medium size companies are all super confuse to what their core business is.
Of course the API is part of the product development and strategy. It isn't something you slap on top of a device .
In case of Fine Offset I can really see how they originally  had in mind a whole strategy with their gateways.
I'm pretty sure they started with the API and build a product around it.
I think the original idea was that other producers would use those API to integrate their own service and hardware and wasn't intended to be release to the public at all.

No argument the API is confusing, and has occasional changes (a no no for those that use it).  For what I use, I just use the custom server option and parse HTTP requests. Not the best thing, but all I need. I can understand your frustration.

Edit: We were ecstatic with even the custom server option when that came about. It allowed a lot of other integrations without being stuck with the standard weather services. I mean most consumer level stuff, don't give you that. I get it is push only, but we didn't have anything at that point.

Some companies understand that they can exploit nerd communities and the whole free and open github generation but don't know exactly how.

The Ecowitt API isn't really that confusing, it is actually better implemented than most API I see around.
I have almost 0 issue with how stable and reliable the whole product is and how graceful they seem to be able to add new devices and backward combability.


My "frustration" is mostly about the commercial side and the confusion about the product capabilities and I express them here just to vent or find other like minded  guys to work with on some fun projects.

[Rover1822]

"From my point of view having a local API would be a no brainer for every kind of IOT device."

I am software development manager for a company that sells an enterprise scale product. Although there is no actual device, I can tell you maintaining an API is expensive in time/labor regardless of the product.  You will notice in this case, even on their forums, you will find little direct support for API use. From my perspective , it was released as an AS IS after thought when they were pressured. From a corporate stand point I kind of get that, cheap device,  supporting an API cost wise ... eh. I know we only sell access to our API, and that is so we can maintain it, document it, etc.

In reality it is not an APi meant for public use by hobbyists. There are, few, like you, that would tackle it compared to the sale figures for the units, which is the goal. It is readily apparent , this was not meant to be something for the casual developer. Most companies would not even think of releasing the API for free, if it meant, that someone could create something to compete with their own products (now or in the future).

Basic business, you want to control  your ecosystem and maximize profit.

Luckily, they did open it up. I really don't expect them to provide support for individual questions on it. Which is why, you are getting your information from in here, on this forum, from others that work with it.

[Gyvate]

provided decoding of post #23 inline - see above

[BadWolf72]

i did not know about this windows app i just seen it so i downloaded the trial version i fill in the ip address and its not working i have provided screen shots.... is this a trail version limitation? i can view my GW1100 on my phone app with no issues.
I have tried rebooting both my windows machine and the GW1100

Thank You
 [ You are not allowed to view attachments ]
 [ You are not allowed to view attachments ]

[BadWolf72]

quick update i left the app running and forgot about it so i open the app getting ready to close it and its working how odd i have not altered or changed anything

[cheeroip]

OK time for a refresh.
 [ You are not allowed to view attachments ]
Next week I'll refresh the app a bit, clean up the protocol and rebranding the things.
(maybe splitting into different use cases since I think EcoWitt is doing a terrible job at explaining their products.

I always look for people to help testing and suggest features.


 

[cheeroip]

I finally had a bit of time to clean up some of protocol mess.

Beta available for free as usual on the microsoft Store

https://apps.microsoft.com/store/detail/ew-gw2000/9MTK0V8DTXSM

Feedback is always appreciated.

Once I'll finalize this I'll update the whole set that market the different models (GW1000 GW1100 WH2640 etc)

 [ You are not allowed to view attachments ]

[olicat]

Hi!

A first quick test ...
Basically a useful Windows programme with a lot of potential.
However, the query via GW1000-API does not yet work completely. But it's still a beta - I'm sure you'll get to grips with that before release.

A few comments:

• DISCOVER does not work yet
• after manually input the ip address the program crashed; after restarting and set units again it seems to work
• show device info tile does not work

About sensors:

• WH45 values do not appear
• I see 16 (!) SOIL sensors (some with the same name) - SOIL1..8 are the WH51 - ok (but they only have the soilmoisture - no need for displaying the temperature
• Sensors 9 - 16 partly from the WH45
• in Live Data I see also 16 soiltemp sensors - there're only 8 at all
• Outddor temperature is not correct (even in °F)
• Indoor humidity is not correct (even on your screenshot)
• 24h AQI#1 is not correct
• AQ#2-4 (non-existent here) all show the same values

And some suggestions:

• it would be nice to have the possibility to disable unused tiles
• one should be able to name the sensors
• I would like to see the battery and/or the reception state
• UI should be also scrollable with keyboard (not only mouse)
• Many users will probably want to be able to arrange the tiles as they wish

I think as soon as the programme works correctly it will find its buyers.

Oliver

[cjohlandt]

Nice app!  Testing with a GW1100.  A couple of observations:

• The decimal point in the rain reporting (in inches) needs to move left one position.  Rain Event shows 5.4, should be .54.  Daily Rain shows 2.6, should be .26, etc.
• All other data looks accurate.
• I like the ability to check the firmware version from the settings screen.
• When I click on the Feeback link in the settings screen, it shows a window with the latest incoming data but no way to enter feedback or send it.
• Agree with the request to disable blocks that aren't used.  I only have the basic sensors.

Keep up the great work!
-Chris

[cheeroip]

Hi!

A first quick test ...
Basically a useful Windows programme with a lot of potential.
However, the query via GW1000-API does not yet work completely. But it's still a beta - I'm sure you'll get to grips with that before release.

Excellent thanks for trying the app.

A few comments:

• DISCOVER does not work yet
• after manually input the ip address the program crashed; after restarting and set units again it seems to work

UDP traffic isn't always the most reactive. Maybe I did set timeouts a bit too aggressive. Keep smashing that DISCOVER button and the gateway should eventually answer.

• show device info tile does not work

Yes, that is an extra tile with some low level info, I'm still not sure if I want implemented in the final version...

About sensors:

• WH45 values do not appear
• I see 16 (!) SOIL sensors (some with the same name) - SOIL1..8 are the WH51 - ok (but they only have the soilmoisture - no need for displaying the temperature
• Sensors 9 - 16 partly from the WH45
• in Live Data I see also 16 soiltemp sensors - there're only 8 at all
• Outddor temperature is not correct (even in °F)
• Indoor humidity is not correct (even on your screenshot)
• 24h AQI#1 is not correct
• AQ#2-4 (non-existent here) all show the same values

I don't know which sensors  a WH45 populate. Take a look under the Device LIVEDATA in the settings and
see if you can recognize the values there.
The 16 humidity values and 16 temperature values are in the protocol. Ecowitt could use them or not use them anytime.
It they are in the protocol I'll show them.
The idea is to give users a useful troubleshooting tool that is as transparent as possible and help them decide what they can buy or not.
Ideally somebody could start sending EcoWitt screenshots to ask which sensor buy.
As now I just feel that their marketing is pretty confusing and not show the potential of the ecosystem.
I honestly have no idea how EcoWitt utilize that outdoor temperature. In my case the outdoor/wind/rain/pressure are all coming from an Ambient Weather station WS2902 that the GW1000 just recognize.
        Indoor humidity is not correct (even on your screenshot)
       24h AQI#1 is not correct
       [AQ#2-4 (non-existent here) all show the same values
I want believe that I left test values there. Those sensors should be pretty straighforward
 PM25_CH1;              // =0x2A, 
 PM25_24HAVG1;      // =0x4D
 PM25_24HAVG2;      // =0x4E
 PM25_24HAVG3;      // =0x4F
 PM25_24HAVG4;      // =0x50
 PM25_CH2;              // =0x51
 PM25_CH3;              // =0x52
 PM25_CH4;              // =0x53
I considered about leaving those markers visible in the application.

And some suggestions:

• it would be nice to have the possibility to disable unused tiles
• one should be able to name the sensors
• I would like to see the battery and/or the reception state
• UI should be also scrollable with keyboard (not only mouse)
• Many users will probably want to be able to arrange the tiles as they wish

Once this ALL-IN version is acceptable is done I'll probably deploy alternative interfaces that will let the user name their sensors.
Would love to have those battery levels but my GW1000 (firmware GW1000B_V1.75) don't return any and I don't understand the protocol implementation.
I'll see how Microsoft implemented tiles but during last years they change their mind so many times and every version works a bit different, add a huge overhead and break combability.

Now that I had a bit of feedback (I didn't even know if the thing was still working outside my house) I'll rush a cleaner version.
Thanks for now

[cheeroip]

Thanks for testing

Nice app!  Testing with a GW1100.  A couple of observations:

• The decimal point in the rain reporting (in inches) needs to move left one position.  Rain Event shows 5.4, should be .54.  Daily Rain shows 2.6, should be .26, etc.
• All other data looks accurate.

That is very weird. I forced a last minute en-US localization for numbers and dates (to avoid commas and points confusion) and I wonder if that broke something./
Do you mind posting a screenshot and paste the result of the LIVEDATA /feedback here?

• I like the ability to check the firmware version from the settings screen.
• When I click on the Feeback link in the settings screen, it shows a window with the latest incoming data but no way to enter feedback or send it.
• Agree with the request to disable blocks that aren't used.  I only have the basic sensors.

Keep up the great work!
-Chris

For this specific version Im thinking to keep EVERYTHING VISIBLE ALL THE TIME....
Once the protocol is solid I'll deploy another version that will HIDE everything not used and give it for free to people that own the more technical and less user friendly.

[cjohlandt]

Thanks for testing

Nice app!  Testing with a GW1100.  A couple of observations:

• The decimal point in the rain reporting (in inches) needs to move left one position.  Rain Event shows 5.4, should be .54.  Daily Rain shows 2.6, should be .26, etc.
• All other data looks accurate.

That is very weird. I forced a last minute en-US localization for numbers and dates (to avoid commas and points confusion) and I wonder if that broke something./
Do you mind posting a screenshot and paste the result of the LIVEDATA /feedback here?

• I like the ability to check the firmware version from the settings screen.
• When I click on the Feeback link in the settings screen, it shows a window with the latest incoming data but no way to enter feedback or send it.
• Agree with the request to disable blocks that aren't used.  I only have the basic sensors.

Keep up the great work!
-Chris

For this specific version Im thinking to keep EVERYTHING VISIBLE ALL THE TIME....
Once the protocol is solid I'll deploy another version that will HIDE everything not used and give it for free to people that own the more technical and less user friendly.

Attached a screen shot of the Rain tile and the Feedback window.  No rain today, but the weekly rain should be .54 and the monthly and annual should be 1.66.  Interestingly, today the Feedback window is showing what looks like hex data - could have also been hex data last night and I misinterpreted.  Also, I had no problem with the discovery - it found my GW1100 right away.

Makes sense to focus on the protocol first.  Again, nice app!

-Chris

[cheeroip]

Attached a screen shot of the Rain tile and the Feedback window.  No rain today, but the weekly rain should be .54 and the monthly and annual should be 1.66.  Interestingly, today the Feedback window is showing what looks like hex data - could have also been hex data last night and I misinterpreted.  Also, I had no problem with the discovery - it found my GW1100 right away.

Makes sense to focus on the protocol first.  Again, nice app!

-Chris

Excellent. Fixed.

l should probably hide better that "feedback" menu....
"Feedback" show exactly what the Gateway return.
"Device" show a more human parsed version and conversions.
In "Main screen" I apply all the necessary unit conversions.

I apologize for all the exceptions, I'm being very disorganized applying the conversions in different spots just because I work on the thing 20 minutes here and there instead of just giving it 4 solid hours lol.

 

[Gyvate]

Interestingly, today the Feedback window is showing what looks like hex data - could have also been hex data last night and I misinterpreted.  Also, I had no problem with the discovery - it found my GW1100 right away.

the hex data is the API response of the Ecowitt Gateway API
If you are interested in more details, read https://www.wxforum.net/index.php?topic=40730.0 chapter 14

[Gyvate]

Attached a screen shot of the Rain tile and the Feedback window.  No rain today, but the weekly rain should be .54 and the monthly and annual should be 1.66.  Interestingly, today the Feedback window is showing what looks like hex data - could have also been hex data last night and I misinterpreted.  Also, I had no problem with the discovery - it found my GW1100 right away.

Makes sense to focus on the protocol first.  Again, nice app!

-Chris

Excellent. Fixed.

l should probably hide better that "feedback" menu....
"Feedback" show exactly what the Gateway return.
"Device" show a more human parsed version and conversions.
In "Main screen" I apply all the necessary unit conversions.

I apologize for all the exceptions, I'm being very disorganized applying the conversions in different spots just because I work on the thing 20 minutes here and there instead of just giving it 4 solid hours lol.

in the version released in the Microsoft store under the link provided
a) CO2-AQ-Combo (WH45) data are in the API response (settings, feedback), NOT is the human readable parsing result (Settings, device) and NOT in the user interface
b) AQ data (WH41/43) for non-existing channels are displayed with the data of the last existing channel (they are not in the API response nor in the parsing result => some field initialization missing)
c) WN34 data are in the API response, also in the parsing results, but not shown in the user interface (they are USER-TEMP and not SOIL-TEMP)
16 completely useless (because non-existing) sensors: SOIL-TEMP1-16 are shown and take unnecessary space in the interface
d) WN35 data is in the API response, NOT in the parsing result and NOT shown in the user interface

imho removing the SOIL-TEMP and displaying the 8 WN34 (USER-TEMP) and the 8 WN35 (Leaf Wetness) instead would solve the user interface space problem
(that the WN35 doesn't show in the parsing results is most likely a programming error, same with WH45 data)

I sent you supporting evidence as text files (feedback [API] and corresponding parsing results [Device] in topic related PMs

It's getting better and better ...

[Gyvate]

one correction:
in my latest download the WH45 data is now also displayed in the user interface
missing the buffer clearance for the WH41/43 sensors - and the display of the WN34 and WN35 sensors
 [ You are not allowed to view attachments ]
EDIT: attached screencopy

[cheeroip]

New Sunday beta (still free) version is out.

https://apps.microsoft.com/store/detail/ew-gw2000/9MTK0V8DTXSM

nothing dramatic on the surface.

moved around the structural protocol so it's just much easier for me to keep the thing modular. /

I finally got all the tiles out.

Still no idea how to get a
Feel like value   (calculated?)
DewPoint         (calculated?)
Air Quality Index   (calculated?)

battery levels
sensors ID



Happy weekend

[Gyvate]

Still no idea how to get a
Feel like value   (calculated?)
DewPoint         (calculated?)
Air Quality Index   (calculated?)

as per the API description ("TCP protool") they should come with the API response: markers 0x03, 0x04, 0x05
the console should have calculated these values

battery levels
sensors ID

via the API - read the description closely 
use
CMD_READ_SENSOR_ID_NEW
on page 9 of the API documentation it says:
"CMD_READ_SENSOR_ID_NEW interpret each sensor for battery status ."
see also page 30 from "31)" on and 33
for other sensors the battery level comes with the sensor data WH45, WH31 ... (see API description)

[cheeroip]

My GW1000 did never return
DewPoint, WindChill or Heatindex.

Code: [Select]

...
0x01 IN_TEMP                C x10: 197       
0x02 OUTTEMP                C x10: 109       
0x03 DEWPOINT               C x10:           
0x04 WINDCHILL              C x10:           
0x05 HEATINDEX              C x10:           
0x06 INHUMI                    %: 45       
0x07 OUTHUMI                  %: 80   
...and I don't think your configuration have those either but the
Ecowitt app WSView have those values (that why the hypothesis  was that they were calculated)


---

DIFFERENT COMMANDS FOR THE BATTERIES AND IDS!!!! I didn't even considered those...

[Gyvate]

I think you messed up a few things with your "corrections" - but not only
a) (superficial) the second column of the Leaf Wetness sensors shows °F where it should be %
b) the WH45 sensors are not properly read/displayed (everything is in the API response though)
if the PM2.5/PM10 sub-sensors show, after a long time passed, they show some "astronomical" values - the CO2 and T/H values are missing
c) the User Temp 1 shows also astronomical numbers - the first two of the three bytes contain the temperature, the 3rd byte has the battery status (value x 0.02)
d) the Leaf Wetness 1 shows a wrong value
e) the PM25 CH4 sensor (WH41/43) shows a ghost sensor which doesn't exist (and no other such sensor around - not shown in the API response either)
0x4D PM25_24HAVG01          μg/m³: 161       
0x4E PM25_24HAVG02          μg/m³: 455       
0x4F PM25_24HAVG03          μg/m³:           
0x50 PM25_24HAVG04          μg/m³:           
0x51 PM25_CH02              μg/m³: 810       
0x52 PM25_CH03              μg/m³:           
0x53 PM25_CH04              μg/m³: 108 
0x53 doesn't occur in the API response ...
not sure how you program, but the detection of the sensors MUST be done in the sequence they appear in the API response and not alphabetically or by sorted HEX values.
Otherwise it won't work. The sequence is shown in my post https://www.wxforum.net/index.php?topic=40730.0 chapter 14

the 0x71 sensor does not exist by the way - for sure no PM25 sensor

09:40:45 PM [ LIVEDATA ]
   OK
Size: 154 bytes

Last Update :   09:40:48 PM
┌───────────────────────────────────────┐
 0xFF 0xFF 0x27 0x00 0x9A 0x01 0x00 0xC0
 0x06 0x30 0x08 0x26 0xF3 0x09 0x28 0x16
 0x02 0x00 0x13 0x07 0x63 0x0A 0x00 0x8F
 0x0B 0x00 0x0B 0x0C 0x00 0x0C 0x15 0x00
 0x00 0x00 0x00 0x16 0x00 0x00 0x17 0x00
 0x2A 0x00 0x8C 0x4D 0x00 0xA1 0x51 0x03
 0x2A 0x4E 0x01 0xC4 0x2C 0x41 0x2E 0x40
 0x30 0x49 0x32 0x2C 0x1A 0x00 0x0A 0x22
 0x5D 0x1B 0x00 0x0C 0x23 0x61 0x1C 0x00
 0x13 0x24 0x62 0x1D 0x00 0x10 0x25 0x62
 0x1E 0xFF 0x38 0x1F 0x00 0x0F 0x27 0x5F
 0x20 0x00 0x4F 0x28 0x3D 0x59 0x00 0x62
 0x00 0x00 0x00 0x00 0x61 0x63 0x76 0x34
 0xD6 0x60 0x25 0x19 0x00 0x6A 0x0E 0x00
 0x00 0x10 0x00 0x0A 0x11 0x00 0x0A 0x12
 0x00 0x00 0x04 0x95 0x13 0x00 0x00 0x04
 0x95 0x0D 0x00 0x02 0x63 0x00 0x05 0x4B
 0x70 0x00 0xC3 0x2F 0x00 0x64 0x00 0x72
 0x00 0x5C 0x00 0x6C 0x03 0x73 0x03 0x33
 0x06 0x72 0x51 0xFB

0x63 TF_USR01               C x10: 346992   
0x64 TF_USR02               C x10:           
0x65 TF_USR03               C x10:           
0x66 TF_USR04               C x10:           
0x67 TF_USR05               C x10:           
0x68 TF_USR06               C x10:           
0x69 TF_USR07               C x10:           
0x6A TF_USR08               C x10:           
SENSOR CO2 (WH45)
0x---- ----                   C x10:           
0x---- ----                       %:           
0x---- ----                     ppm:           
0x---- ----                     ppm:           
0x---- ----                   μg/m³:           
0x---- ----                   μg/m³:           
0x---- ----                   μg/m³:           
0x---- ----                   μg/m³:           
SENSOR
0x71 PM25_AQI               -----:           
0x72 LEAF_WETNESS_CH01      -----: 0         
0x73 LEAF_WETNESS_CH02      -----:           
0x74 LEAF_WETNESS_CH03      -----:           
0x75 LEAF_WETNESS_CH04      -----:           
0x76 LEAF_WETNESS_CH05      -----:           
0x77 LEAF_WETNESS_CH06      -----:           
0x78 LEAF_WETNESS_CH07      -----:           
0x79 LEAF_WETNESS_CH08      -----:   

[stevenh]

I'm testing the GW2000 V0.99.
A lot to like.
If not mentioned before, the compass wind pointer is 180 deg out of phase with the numerical reported value.

Steve

[Gyvate]

 [ You are not allowed to view attachments ]
to show a few of the inconsistencies in the interface mentioned earlier
a) WH45 not showing, not showing in the parsed table, showing in the API response
b) WN34 CH1 wrong number, as mentioned above you have to use the first two bytes, not all three bytes
c) what temperature is supposed to be shown at the wind tile ?
d) the wind direction is showing correctly in my case, under the console calibration I have a 90° offset, but this is considered in the API response
e) the WN35 CH1 value now correct, after some time - not sure what "dirt effect is going on" - but parsed table and interface are consistent - only sometimes wrongly translated from the API response (some buffer initialization issue ?)