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.
On Tuesday, October 14, 2025 at 1:06:24 AM UTC-7 Rainer Lang wrote:
> 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. !!
> On 13.10.2025 20:27, vince wrote:
>
> 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.....
>
> --
> 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 [email protected].
>
> To view this discussion visit
> https://groups.google.com/d/msgid/weewx-user/c1c94948-8e21-4249-85da-fd4aaa726127n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/weewx-user/c1c94948-8e21-4249-85da-fd4aaa726127n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/6e7fad91-f1cf-4fe3-9e3a-7d1da3b82277n%40googlegroups.com.
