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 >> - 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/60800b0f-71fd-4137-b277-a17a6be0f288n%40googlegroups.com.
