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/e7672001-ab57-474b-8c56-fff3bd2ecd05%40gmail.com.
