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. 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. On Tuesday, October 14, 2025 at 9:59:58 AM UTC-7 vince wrote:
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
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].
--
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/60800b0f-71fd-4137-b277-a17a6be0f288n%40googlegroups.com.
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/6091066B-0EDC-47C4-89FB-D5054BD5B9B5%40btinternet.com.
|
