In terms of the documentation, it would be nice to have more robust explanation of what each section does. Perhaps even a diagram that shows the flow of information within the extension. I would say if there is a REPLACE_ME value in the extension I found myself having a hard time with "replace with what exactly". So a bit of explanation of each level would help, maybe with an example. Examples are extremely helpful.
On Sunday, July 12, 2026 at 4:24:31 p.m. UTC-4 [email protected] wrote: > 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/a84d9122-858f-4046-9711-e104e1551ca3n%40googlegroups.com.
