MQTT extension comments

[Greg Troxel]

I've just set up the MQTT extension and have a few random
comments/suggestions, plus I wanted to say thanks for making it
available.

While trying to configure the three pressure values to hPa, I reread the
rest of my config and saw "group_pressure = hPa" in
StdReport/Defaults/Units/Groups. It was nice to be able to set that
once. It occurs to me that the MQTT publisher is a bit of a skin, in
that it's sending data from weewx, except that it's aimed at machine
consumers. It would be perhaps nice for me, perhaps suboptimal for
others, if the units followed the defaults in
StdReport/Defaults/Units/Groups. I'm guessing that whether this is good
or not is highly dependent on what people are doing, so I will stop
short of requesting it!

It seems that if you use the wrong case for a value it doesn't match
(Barometer vs barometer, a camelCase thinko), but that there isn't an
error. Throwing an error on an unknown variable would probably help
people debug their configs faster.

At some point while configuring, I wanted an easy way to publish only a
specified subset of values, and omit the rest. But with the "aggregate"
approach, this is much less desirable.

One of the things I find hard about MQTT is that while it's somewhat
like (being fuzzy) TCP/UDP/IP as a transport layer, there don't seem to
be specifications that lay out what subtopic names to use and what the
contents should be. It seems clear that the schema used by the MQTT
publisher and the the Belchertown skin listener match, and that this is
both not accidental and necessary. If there are any specs like that
related to weather, it would be nice to link them from MQTT wiki page.

If anyone knows of weewx Home Assistant integrations, those too would be
nice to link to from the MQTT wiki page. This doesn't seem hard to
write, listening to MQTT and injecting, but I would expect it's been
done before. (I was surprised not to find them within the Home
Assistant world but maybe I didn't look well enough.)

As part of debugging my install, I read parts of the code and noticed
the import of cjson, and installed it and added it to the wiki
instructions before realizing there are three modules tried, and that
the last, "json" is built in to python. So probably I should undo the
advice to install cjson, but perhaps people think cjson is better and
that users of MQTT should actually be told to install it.

I didn't see mention of qos in the wiki page. I am still unclear on
what I want to do about qos/retain, and use of mqtt to have listeners
get current data vs also recording data in a database, and how to handle
time periods when there is network disconnection. That's not a request
for explanation of particularly the bigger pictture now -- I have more
reading, thinking and experimenting to do, but if there is a
well-developed notion of setting qos in the publisher and someone who
wants understands that to add it to the wiki or mention it here, that
would be great. (This issue is arguably more important when using
microcontrollers with batteries to observe values without losing them if
the weewx machine or the network is down for a while.)

I see that the publisher, when set for archive records only (5 min
interval), connects and disconnects each time. That seems sensible, but
I wonder about the staying-connected approach, and am not sure which is
more normal in MQTT culture or which leads to better outcomes. With
always connected, the publisher could (usefully) register a "last will
and testament".

[Greg Troxel]

A further nit about units. I did the following

[[[inputs]]]
[[[[barometer]]]]
units = hPa
[[[[altimiter]]]]
units = hPa
[[[[pressure]]]]
units = hPa

which changed my json from

"barometer_inHg": "29.926"

to

"barometer_inHg": "1013.41052041"

I realize I can set the name, but perhaps the name should be ge<nerated
from the used units rather than the database or standard units.

[Pat]

Hi Greg, here's some of my thoughts on your thoughts.

> One of the things I find hard about MQTT is that while it's somewhat like (being fuzzy) TCP/UDP/IP as a transport layer, there don't seem to be specifications that lay out what subtopic names to use and what the contents should be.  It seems clear that the schema used by the MQTT publisher and the the Belchertown skin listener match, and that this is both not accidental and necessary.  If there are any specs like that related to weather, it would be nice to link them from MQTT wiki page. 

I don't think there's any official specifications for MQTT topics. In general, the topics (and subtopics) can be whatever you want them to be. In the case of weewx-mqtt the LOOP is in the LOOP subtopic, and the individual readings are in their individual topics (like outTemp, barometer, etc.). This info is in the weewx-mqtt wiki.

With the Belchertown skin you need to specify the LOOP topic (and not #) if you use the weewx-mqtt extension. Belchertown is not married to this extension though, just the schema within the LOOP topic. So in theory you could point the skin to any other MQTT broker or weather system and so long as the topic payload schema is identical to weewx-mqtt's, it should work. So there's flexibility here for those who may not use weewx. 

> If anyone knows of weewx Home Assistant integrations, those too would be nice to link to from the MQTT wiki page.  This doesn't seem hard to write, listening to MQTT and injecting, but I would expect it's been done before.  (I was surprised not to find them within the Home Assistant world but maybe I didn't look well enough.) 

I'm using Home Assistant with my MQTT broker as well, but I don't have any automation setup for use with my weather data though. I just show outTemp on my Lovelace home page for now. Here's the yaml I'm using. I just subscribe to my broker's loop topic, then grab the specific outTemp_F value. Once it's in hass, you can use it for any kind of automation though.

sensor:
  - platform: mqtt
    name: "Outside Temperature"
    state_topic: "weather/weewx/loop"
    unit_of_measurement: "F"
    value_template: "{{ value_json.outTemp_F }}"
    icon: mdi:temperature-fahrenheit

    

> I see that the publisher, when set for archive records only (5 min interval), connects and disconnects each time.  That seems sensible, but I wonder about the staying-connected approach, and am not sure which is more normal in MQTT culture or which leads to better outcomes.  With always connected, the publisher could (usefully) register a "last will 

and testament". 

I'm not sure about this one either on what's "right" to do, but my thought here is that MQTT was developed for remote areas with limited connectivity so maybe thats why the connect, publish, disconnect? Minimum bandwidth needed.

> I realize I can set the name, but perhaps the name should be ge<nerated from the used units rather than the database or standard units. 

I agree 100%. I have asked mwall to put weewx-mqtt onto his GitHub so I can help with some updates to it. This could be a good enhancement as well.

[mwall]

On Tuesday, August 6, 2019 at 10:36:07 AM UTC-4, Greg Troxel wrote:

I realize I can set the name, but perhaps the name should be ge<nerated
from the used units rather than the database or standard units.

i would consider this a bug in the extension; when 'append_units_label' is True, the label that is appended should respect any overrides.

thank you for the other comments and suggestions too!

i've got a lot of landscaping to work through this weekend, but maybe i can get the subversion repositories converted over to git when the sun is not shining...

m