"[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/rmimrvoe46o.fsf%40s1.lexort.com.

Reply via email to