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