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.
On 14.10.2025 20:47, 'steepleian' via weewx-user wrote:
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 <[email protected]> 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.
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
o http://x.x.x.x/get_sensors_info?page=1
o http://x.x.x.x/get_sensors_info?page=2
o 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/60800b0f-71fd-4137-b277-a17a6be0f288n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/60800b0f-71fd-4137-b277-a17a6be0f288n%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/6091066B-0EDC-47C4-89FB-D5054BD5B9B5%40btinternet.com
<https://groups.google.com/d/msgid/weewx-user/6091066B-0EDC-47C4-89FB-D5054BD5B9B5%40btinternet.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/5a8f47a7-c757-4989-a7aa-16ecac6b97d7%40gmail.com.
