WeeWX-MQTTSubscribe - how to suppress debug=1 logging

[vince]

Rich:

I just installed the service and have it adding my outside room DS18b20 temperature sensor data to weewx via MQTT and it's very much simplified my setup.  Many thanks !!!

But...how do I turn the debugging logging off for your extension only ?   When I run weewx with debug=1 my log is filling quickly with lines like:

May 22 10:13:28 debian weewx[23343] DEBUG user.MQTTSubscribe: (Service) data-> final packet is 2021-05-22 10:13:29 PDT (1621703609): barometer: 30.153,.........

I'm guessing this has something to do with the new logging in recent weewx, but I haven't kept up with how to tune that service by service.   Any pointers ?

Note - I have a lot of MQTT stuff going on here if that matters.  My weewx is publishing to MQTT so I can pick up the data in Home Assistant.  I have a second weewx instance in docker doing the same for my Ecowitt setup.   I have all kinds of other things publishing to MQTT as well.

Secondary question: how would I get your extension to send 'some' things it is subscribing to into a secondary weewx db ala 'data_binding = whatever' ?   I know your extension won't create that db, but assuming it's there already (mine is) how would I bind just 'some' subscribed topics to the db of choice ?

But the logging is the primary question.  I'm fine with using the extra fields in the extended weewx schema if necessary.

Thanks again for the extension, it 'massively' simplifies my setup for getting secondary sources of information into my primary weewx setup !

[bell...@gmail.com]

Thanks for the kind words.

re: logging

I think you are looking for this, https://github.com/weewx/weewx/wiki/WeeWX-v4-and-logging#customizing-what-gets-logged

So adding the following should work.

[Logging]

  [[loggers]]

    [[[user.MQTTSubscribe]]]

      level = INFO      

Note, I usually do the reverse and only turn on 'DEBUG' for the modules I care about...

re: additional db/binding

I hadn't thought of this use case, so currently you can't. Because the WeeWX aggregation of loop packets into archive records, is leveraged I don't think this would be easy. Unless writing the loop data to a DB is what you want.

rich

[vince]

On Saturday, May 22, 2021 at 1:22:31 PM UTC-7 bell...@gmail.com wrote:

re: logging

I think you are looking for this, https://github.com/weewx/weewx/wiki/WeeWX-v4-and-logging#customizing-what-gets-logged

So adding the following should work.

[Logging]

  [[loggers]]

    [[[user.MQTTSubscribe]]]

      level = INFO      

Note, I usually do the reverse and only turn on 'DEBUG' for the modules I care about...

Yup - worked fine.  Thanks. 

re: additional db/binding

I hadn't thought of this use case, so currently you can't. Because the WeeWX aggregation of loop packets into archive records, is leveraged I don't think this would be easy. Unless writing the loop data to a DB is what you want.

In my case I'm emitting the MQTT data from the satellite sensors only once every 5 minutes so I guess it is the same result either way re: loop or archive and what goes into the database, but it's not a big deal.   Those particular sensors are just nice-to-have anyway, but I was curious because I have my old secondary db (that can go away now) that I was thinking of putting the new data into after I disable my more complicated setup from fall 2014 (really).   It'll be great disabling all that old stuff and doing it the easy way now :-)

[vince]

Only loosely related, but I thought I'd pass along a network diagram of my home setup 'after' implementing the mqtt-subscribe extension to simplify aggregating data from two weather stations, one raspberry pi, and multiple arduinos with everything eventually getting rsync'd to my public facing website.

[bell...@gmail.com]

Very cool to see.  Thanks!

[bell...@gmail.com]

Since it is working for you and now it is so easy to add columns to WeeWX DBs, I’m not going to pursue this further. Honestly, if someone had to have a separate DB I’d nudge the to running MQTTSubscribe as a driver in a separate instance….

rich

[Graham Eddy]

inspired by vince, i thought i should share my architecture since moving to messaging backbone (mqtt) - i moved major weewx services out of weewx into free-standing reusable mqtt components

comments:

• weewx-alarm now malarm - content of incoming payloads mapped to variables, then rules (python) applied to evaluate states of alarms, which are themselves published on mqtt. they also execute nominated python classes on state transitions (usually emal!)
• i am moving my many watchdog checkers (e.g. is riverLevel column being updated regularly?) to just send mqtt message, to be picked up and monitored by malarm
• mbrowser - javascript app discovers mqtt topics and displays their values in 'real time’. (alarm-oriented sub-view nearly complete)
• my own higher level python API above mqtt (bi-directional gateway) for all my mqtt apps → my own equivalent to MQTTSubscribe over this API is just another mqtt app
• DMZ: transitioning from current webhost to my own VPS where i will also publish payloads filtered through a bridge. (nearly ready to go. found a VPS provider in australia with reasonable prices. my VPS will be primary name server with a free secondary name server from hurricane electric www.he.net - thanks to this forum for the advice)
• wx growth is through adding custom instances of weewx and other components, not over-loading single instance of weewx with many services