I realized that without the retain, the HA plugin had nothing to work with because the timing on my weather data is so different depending on what it is, my wind data is every 5 seconds and my archive period is 3 minutes so all my other raw data from my weather station posts every 3 minutes as well. Because everything is so out of sync I have to use retain or it will never get anything to work with. Also as far as the LWT, I just AI'd it and it suggested that HA enjoys having that set. I did set up MQTTPublish and the HA plugin with json because I had no reason to break out the topic individually. My raw data from my weather station on the other had posts individually.
On Sunday, July 12, 2026 at 1:10:23 p.m. UTC-4 Greg Troxel wrote: > "[email protected]" <[email protected]> writes: > > > 2. Explain that LWT needs to be set. > > This is a consequence of the choice of config data (or, if not using > that, of how one configures Home Assistant). Really, this is about an > MQTT receiver in general, not specifically HA. > > As I see it, the standard approach is more or less to have a topic for a > device called "foo" as blah1/blah2/foo (henceforth just foo) -- that > does not get written to, usually, and then > > foo/online > > foo/temp > foo/humidity > > foo/json > > except I don't claim /json is normal. Maybe it should be. > > HA then has a binary sensor from foo/online. Values might be ON and > OFF, to align with the HA MQTT default values for binary sensors, or > online and offline, to align with the default values for availability > topics. Probably online/offline is best as then the availability_topic > doesn't need value config. > > The sender transmits foo/online = online at connection time. It sets a > LWT to set foo/online = offline, so that when it goes offline, the > broker sends that update, and receivers know it's gone. That's *if the > receiver is still connected to the broker*. > > One also typically sets a timeout using "expire_after" so that even if > the broker goes away, the receiver will stop using the value. > > See > https://www.home-assistant.io/integrations/binary_sensor.mqtt/ > for more. > > The binary sensor is useful for alerting, to report lack of "weewx > connected". But probably you also want (I do) a "weewx reporting" > template sensor that is true if e.g. the temperature has a valid value, > and false if it's "unavailable" or "unknwown", and to alert on that > also. > > If you don't want to have an availability topic, that's ok -- this can > be done with just expire_after. > > I use an archive interval of 5m (300s), send archive data via MQTT, and > have configured expire_after to 330s. So it blanks out on a missed > update with 30s grace/jitter, and I alert after 6 minutes of the sensor > (so that one missed update does not alert me, but two do). I do not use > availability topics for weemx mqtt. I'm running the older extension and > haven't mesed with it in years. That's me; not saying it's the right > approach. > > So you don't need LWT, if you don't want to have an /online topic. If > you post online=true at startup, you do. If you don't have a > functioning /online topic, you can't use availability_topic. > > > 3. Explain about retain (I will probably need to ask some more detail > about > > this.) > > My take from years of MQTT with HA and weewx (and helping with mosquitto > packaging and upstream): > > Values that are semi-permanent transitions, not likely to change for > long periods, and which are not routinely retransmitted, should set > retain. Periodic measurements should not set retain. > > This means that foo/online gets retain. It's written on connect and > might stay that way for weeks. When a receiver boots or reconnects, it > needs to know the last value. > > State measurements -- temperature etc. -- are ephemeral. The last > reported temperature, after reports stop for some reason, isn't really > related to the current temperature and should not be used as a such. If > you don't have a current value the value is "unavailable" (a HA > codepoint). > > (Yes, one could send tuples of (time, temp), and the receiver could > carry these to the db, but it should still treat them as expired as far > as the current value goes. But if you want to do database sync you > should do that, and what we're talking about is separate.) > -- 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/37eebb00-661f-4188-8ae4-de170d7bf066n%40googlegroups.com.
