"Point 2 reveals that the "configuration json" config is not independent of the configured topics. There should be an integrated config the the publisher, and the configuration json should just be on or off, with a choice of what topic to publish it under.""
I agree. That is why I consider MQTTConfigHA (publishes the configuration data) a 'plugin' to MQTTPublish (publishes the data). MQTTPublish can exist/run without MQTTConfigHA, but MQTTConfigHA requires MQTTPublish. "2) The configuration json data should be aware of whether the online topic is enabled or not. If it's not, there should be no availability topic. Solved by making it not optional." Yup, I just had a bug that forgot to chek if the online topic was enabled. So MQTTConfigHA was always 'saying' there was an availability topic, even when there wasn't. "1) Make the online topic the standard approach. There is in my view no good reason to omit it. It's useful in HA to know "is weewx connected", which can be used for alerting. It's just a biuary sensor that rarely changes, so it has ~zero cost compared to N weather entities." I believe it is. The availability topic is the MQTTPublish's LWT topic. It is on by default. It has a default payload that align withs HA, but can be configured (in case MQTTPublish is publishing to something else (in addition to HA or instead of)). rich On Saturday, 18 July 2026 at 10:57:27 UTC-4 Greg Troxel wrote: > "[email protected]" <[email protected]> writes: > > > By dumb luck, I think I have a handle on what is happening. The key is > > setting LWT in MQTTPublish. This also sends a “birth” message. Without > > this, HA thinks everything is “unavailable”. I have to dig a bit more > into > > MQTTPublish code and HA docs. > > That makes sense. > > Calling it LWT is confusing. The point is that there is an online topic > which gets "online" at starteup, and has LWT set to send "offline" on > disconnect. It's not about LWT so much as haivng an online topic; the > LWT part is a detail. > > The configuration json must be referencing the online topic. That's > fine. > > I recommend that config for an online topic be limited to setting the > topic, and optionally to set the payloads (but I would align defaults to > HA's defaults for availability topic, which are different from defaults > for binary sensors!). If it's set, that means both published at start > and LWT, both retain=YES. I don't think it makes any sense to omit LWT > if you publish at start, and it doesn't make sense to do retain=no. > > We have a culture of infinite configuration, but let's only let people > configure things when there is an articulated rationale -- otherwise > it's just a source of chaos with no value. > > Two approaches here: > > 1) Make the online topic the standard approach. There is in my view > no good reason to omit it. It's useful in HA to know "is weewx > connected", which can be used for alerting. It's just a biuary sensor > that rarely changes, so it has ~zero cost compared to N weather > entities. > > > 2) The configuration json data should be aware of whether the online > topic is enabled or not. If it's not, there should be no availability > topic. Solved by making it not optional. > > > Point 2 reveals that the "configuration json" config is not independent > of the configured topics. There should be an integrated config the the > publisher, and the configuration json should just be on or off, with a > choice of what topic to publish it under. > > > I leave heavily to regularizing the setup towards the consensus best > practices, and making it fancier only when there's a good argument for > that. > > > -- 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/81cc7dac-f687-4224-b660-450fd2886a2fn%40googlegroups.com.
