GW2000 Ecowitt LDS-01 driver ?

[Tim Tuck]

Hi all,

I've just installed an LDS-01 in our main rain tank and I was just
wondering if anyone has made progress incorporating that into any drivers ?

A quick search of the forum emails didn't turn up anything specific so I
thought I'd ask.

thanks

Tim

[vince]

Which driver are you currently using ?   If you can provide some data perhaps somebody can take a crack at it....

[steepleian]

Vince, I am away at the moment with weak internet access. Could you point Tim in the direction of the Ecowitt http local driver please which covers the level detector.

Thanks

https://claydonsweather.org.uk

On 7 Oct 2025, at 16:43, vince <vince...@gmail.com> wrote:

Which driver are you currently using ?   If you can provide some data perhaps somebody can take a crack at it....

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/def7d7f4-3553-4a1c-9d26-078aa74a900cn%40googlegroups.com.

[vince]

Sure .....   Tim - the http local driver Ian mentions is at https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development - looks like internally that model maps to a WH54 name which is what you'd need to use in any field_map_extensions in your weewx.conf (if needed)

Gary's original gw1000 driver does not seem to support the LDS-01/WH54 but he does have some diagnostics in the source tree that I used to help him add support for the WS85 last year.  If you'd like me to try to take a crack at looking at that driver contact me offline via email and I can try to walk you through getting me the info needed to see if that's reasonably possible or not.

[steepleian]

Thanks Vince.

https://claydonsweather.org.uk

On 7 Oct 2025, at 17:53, vince <vince...@gmail.com> wrote:

Sure .....   Tim - the http local driver Ian mentions is at https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development - looks like internally that model maps to a WH54 name which is what you'd need to use in any field_map_extensions in your weewx.conf (if needed)

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/8c187484-d4ca-4971-b929-7075a5a4c9b8n%40googlegroups.com.

[Tim Tuck]

Hi Vince,

Thanks for that.

I'm currently using the gw1000 on my main server and it doesn't see the new data

I'll give the http driver a try on my devtest build of my weather server to see what I can see.

I'll definitely ping you if I need help.

thanks

Tim

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/8c187484-d4ca-4971-b929-7075a5a4c9b8n%40googlegroups.com.

[Rainer Lang]

the GW1000 driver uses the binary API of the consoles/gateway - however, this binary API does not support all the newer sensors and is no longer updated.
A WS90 is supported and from an API point of view a WS85 and a WS90 are the same regarding wind and rain data.
But when it comes to more recent sensors like the WH54/LDS-01, its data (and those of future sensors) can only be retrieved via
the local http API. Therefore, LDS-01 data only via the http API driver.

See also: https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#apis_application_programming_interfaces

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/7dfde45c-be5e-41bd-afad-0030121b6aed%40skybase.net.

[vince]

Such a difficult wiki to battle through….and Tom says ‘weewx’ is past ‘max documentation’. Wow :-)

I continue to wonder if just going MQTT with a mosquitto broker on the weewx host might be simplest long term solution for a no backfill required setup, but there are so many oddities in how ecowitt names things it’s hard to say.  They are certainly inconsistent.

The gw1200 at least supports MQTT now with the latest firmware. Seems to work in brief testing…

[steepleian]

So maybe the perfect solution is MQTT with a backfill process built in?

https://claydonsweather.org.uk

On 13 Oct 2025, at 16:29, vince <vince...@gmail.com> wrote:

Such a difficult wiki to battle through….and Tom says ‘weewx’ is past ‘max documentation’. Wow :-)

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e004f8b9-7f26-4cb0-9a44-41e28e7b3701n%40googlegroups.com.

[vince]

On Monday, October 13, 2025 at 9:45:57 AM UTC-7 steepleian wrote:

So maybe the perfect solution is MQTT with a backfill process built in?

Uncertain.  Some folks might not want to run a MQTT broker although it's easy and lightweight on Linux.

Ecowitt uses so many formats and naming conventions that it's difficult to suggest what the best path forward might be.  I certainly find the MQTT easier to read and should be far easier to program to (for me at least) since we already have the nice MQTTSubscribe driver/extension that can handle the annoyances in how Ecowitt returns the MQTT data.

Re: content.....

MQTT seems more current than the HTTP API data for my gw1200 running latest firmware that came out recently:

• MQTT has additional info missing from HTTP (vpd, soil moisture ADC value, gateway model, gateway freq)
• MQTT and HTTP report battery levels much differently it seems
• MQTT makes absolute and relative pressure easily both available, HTTP has an item that 'seems' to be the offset in kPa (?)
• HTTP structure for how it reports rain is just odd.  They have hardware info in the same element as the yearly rain totals
• HTTP is also odd in their model identifiers.  My gw1200 inside temp/hum/pressure info comes up as being from a wh25 (!!!!)
• getting HTTP data can mean dealing with that horrid "page=N" thing and assembling things from multiple pages of data
  • http://x.x.x.x/get_sensors_info?page=1
    
  • http://x.x.x.x/get_sensors_info?page=2
    
  • then assembling them in some order based on type id value

That said....Ecowitt MQTT isn't perfect either

• sensor RSSI and 'signal' (whatever that is) is only available via HTTP get_sensors_info if that matters to you
• and MQTT returns a HTTP POST header and multiple blank lines, using WU protocol formatting with & rather than , as the delimeter, but folks have already reported and worked that issue here with how to set up MQTTSubscribe to deal with that annoyance so while it's ugly it's easy to work around

I'll attach a txt file with the data I see here with a little light editing to make it easier to go through.....

[Claudio]

weectl extension install https://github.com/gjr80/weewx-ecowitt_local_http/releases/latest/download/ecowitt_http.zip

page not found

where can I find this file?

thanks

Claudio

[vince]

Go to https://github.com/Millardiang/weewx-ecowitt_local_http/tree/development and copy the download zip URL by right clicking on that button.Then use that URL in your command.

[Claudio]

Thanks Vince

[Rainer Lang]

from a wider perspective as weewx is certainly not the navel of the world as we say in my language:
using MQTT for a customized server posting in an Ecowitt console is not helpful if another customized server target is also already used or needed - there is not more than one per console
that's where the API requests drivers bring in their advantages including polling interval advantages while customized server posting is limited to 8 seconds (and users of a WS80 appreciate their 4.75 second sensor data update interval - and leaving the customized server post feature free for other needs

the move from the binary API to the http API is imho the right thing to do.
Complaining about payload content is not going to lead anywhere - why would they create a new payload content for every protocol supported ?
Obviously, people using e.g. HomeAssistant and use the Ecowitt MQTT posts manage well - even though there is now a local http API based HA integration which reads the console data in real time - the equivalent of the weewx local http API driver which in my observation is very close to being complete. 🙂
Good, even excellent work Ian, Werner, Michael etc. !!

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/c1c94948-8e21-4249-85da-fd4aaa726127n%40googlegroups.com.

[vince]

We can disagree.  I disagree.  Some thoughts:

• Re: payloads - if somebody is going to emit MQTT then follow the spec and emit 'valid' MQTT.  That simple. Ecowitt emitting a WU-centric HTTP POST header and content in their MQTT output 'and' using the wrong delimiter to match a legacy Weather Underground expectation is simply lazy.   All they did is reuse their post code and emit it as an invalid MQTT payload.  That is weak.

• Furthermore, WU as a service continues to degrade and nobody can predict when that service will eventually go under.  They're yesterday's news.  Ecowitt is emitting invalid format data centered around a company that is a decade into its spiral toward going out of business.  Nobody can predict what the private equity company that purchased WU last year from IBM will do, or not do.
  

• Re: one custom server - my belief is having weewx and a 'weewx' driver implies that the user is going to have weewx do the heavy lifting, so to speak, for posting to Internet sites.  So ecowitt hardware/software being limited to only one custom server location is irrelevant. If you're a weewx site you do not 'need' more than one custom server enabled.

• It doesn't matter how often the gateway can emit MQTT if the sensors do not 'measure' their hardware that frequently.  Other than trying to capture very rapid wind changes, I see no value in worrying trying to be faster than 8 seconds between measures (using your numbers), or MQTT posting every 10 seconds which is how fast my GW1200 can post.

If you want to see a company that does APIs 'well', look at WeatherFlow and their UDP local and REST/websockets APIs.  They are well documented.  They keep them up to date.  They have worked from the beta days before their first product even existed pre-release.  Regardless of whether you might consider  their gear is/isn't good enough, they certainly did that part very well.

My belief is that setting the gateway to emit MQTT (and leveraging Rich's excellent MQTTSubscribe driver/extension) is the most standard, modern and sustainable way to deal with Ecowitt, although backfill and Ecowitt having yet another way they save data to deal with is a problem in itself.

For a no-backfill-required site, such as mine here, MQTT is by 'far' the simplest way to deal with ecowitt's oddities.

[vince]

I might add that if you use MQTT as the driver then you would not need 'any' ecowitt driver at all to handle incoming data.  Just a standalone service to handle how to backfill the db from the saved files on the gateway SD card.     MQTTSubscribe driver + ecowitt backfill service.  Or Ecowitt backfill-only driver + MQTTSubscribe as a service.  Whatever makes most sense.

[steepleian]

I can see both sides of the argument but ultimately I generally agree with you Vince as we are specifically here to discuss WeeWX solutions. 

I mentioned the other day my perfect ideal of catchup partnered with MQTT. I have a proof of concept already working as a straight non WeeWX python service (the way I normally work things through). In essence, the payload is converted on the fly into a ‘conventional’ format before it is published. It then becomes very much easier from that point. The catchup part is pretty much a direct drop in of Gary’s original code and can be switched on or off via WeeWX.conf as a user preference.

Likewise the frequency will be a user configurable item.

On 14 Oct 2025, at 18:43, vince <vince...@gmail.com> wrote:

I might add that if you use MQTT as the driver then you would not need 'any' ecowitt driver at all to handle incoming data.  Just a standalone service to handle how to backfill the db from the saved files on the gateway SD card.     MQTTSubscribe driver + ecowitt backfill service.  Or Ecowitt backfill-only driver + MQTTSubscribe as a service.  Whatever makes most sense.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/60800b0f-71fd-4137-b277-a17a6be0f288n%40googlegroups.com.

[Rainer Lang]

not all Ecowitt consoles which have an http API can and will ever post with MQTT.
The MQTT solution is in my view (architecture-wise) a variant of the interceptor driver solution - whereas Gary's drivers use the binary and http API.
I count on Werner getting the loose ends for the httpEcowitt driver fixed what he already did to quite some extent
(if not even completely - I might not know the latest status here).

And if someone wants to bring in a MQTT based solution - fine - might even replace the meanwhile completely extended interceptor solution (also by Werner) -
but why ? As that extended interceptor solution works perfectly well. So using the Ecowitt customized server option is already settled.
No MQTT needed, no payload conversion needed - it's already all there.

And with all that discussion I keep on wondering how the authors of CumulusMX and Meteobridge managed to implement the Ecowitt http API, 
CumulusMX even both backfill methods. Successfully operative for quite some time now. 

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/6091066B-0EDC-47C4-89FB-D5054BD5B9B5%40btinternet.com.