possible for weewx to accept data via MQTT devices?

[Eric Koester]

I'm currently reading data into weewx using an Acurite Atlas, an RTL-SDR, rtl_433, and weewx-sdr.

I'd like to import barometric pressure sensor data into weewx via MQTT from a wifi pressure sensor.  Is that possible?  

If yes, is it possible to import data via 2 different drivers?

The potential plan is to connect an BME280 sensor (via i2c) to a ESP8266 wifi module loaded with Tasmota open-source firmware.
see:  https://tasmota.github.io/docs/BME280/

Tasmota sends the data a tele/%topic%/SENSOR JSON response.

Assuming that weewx can accept data via MQTT, I'm not sure what the device-facing variable name would be inside of weewx.

example of known device-facing variable name:  

outTemp = temperature.001.AcuriteAtlaspacket

[Peter Gillbrand]

Check this: https://github.com/bellrichm/WeeWX-MQTTSubscribe

[Eric Koester]

Thanks for the pointer, Peter.

I looked through the install instructions and I don't see any mention of the weewx.conf file.

Does anyone know:

1. does MQTT need to be declared as a station_type in the weewx.conf file?

2. if so, is it ok to have more than one station_type in the weewx.conf file?

Right now, I've got my station_type set to SDR so I can accept weather station data via an RTL-SDR and rtl_433.

example:

##############################################################################

#   This section is for information about the station.

[Station] 

    # Set to type of station hardware. There must be a corresponding stanza

    # in this file with a 'driver' parameter indicating the driver to be used.

    station_type = SDR

Thanks for all the info.
Eric

[Greg Troxel]

Eric Koester <eric.k...@gmail.com> writes:

> Thanks for the pointer, Peter.
> I looked through the install instructions and I don't see any mention of
> the weewx.conf file.

DId you read

https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring

Agreed that it doesn't say that it is talking about the config file.

A big point is driver vs service. It seems clear that you want
service, where MQTT input is secondary.

[Eric Koester]

> DId you read
> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring

No, I wanted to make sure MQTT was usable simultaneously with another weewx "driver", before I spent a lot of time on it.

Thanks for the pointer to service vs. driver configuration!

I'll read through it.

[Peter Gillbrand]

I have manage to get a weather station to be the main provider of data to R-Pi based Weewx installation with add on data into the database coming from a sensor providing MQTT messages. If that it is similar to what you are aiming for,  maybe this conversation can provide guidance https://github.com/bellrichm/WeeWX-MQTTSubscribe/discussions/132

[Eric Koester]

That does sound similar.  Thank you for that pointer!

I want to get the Tasmota firmware to output MQTT messags containing the barometric pressure. 

Then, weewx would need to take in that MQTT message and assign the data to the stock 'barometer' variable from the database schema.

[bell...@gmail.com]

A few additional things to consider.

From, https://tasmota.github.io/docs/BME280/, your json data is ‘nested’. Meaning the incoming names in MQTTSubscribe will be BME280_Pressure, BME280_Temperature, and BME280_Humidity. 

You will want to use the ‘ignore’ option for PressureUnit and TempUnit.

Due to the way MQTTSubscribe handles date/time data, the Time field is a bit more interesting. I would also ‘ignore’ it. This just means that MQTTSubscribe will not try to check that the data is in the time interval being processed by WeeWX. 

Configuring MQTTSubscribe can be a bit daunting, so just shout with any additional questions.

rich

[Eric Koester]

On Tuesday, May 4, 2021 at 3:52:59 PM UTC-5 bell...@gmail.com wrote:

A few additional things to consider.

From, https://tasmota.github.io/docs/BME280/, your json data is ‘nested’. Meaning the incoming names in MQTTSubscribe will be BME280_Pressure, BME280_Temperature, and BME280_Humidity. 

What config file do you enter these incoming names into?

 

You will want to use the ‘ignore’ option for PressureUnit and TempUnit.

What config file do you put the ignore option into?

 

Due to the way MQTTSubscribe handles date/time data, the Time field is a bit more interesting. I would also ‘ignore’ it. This just means that MQTTSubscribe will not try to check that the data is in the time interval being processed by WeeWX. 

What syntax do you use to tell it to ignore the date/time data?
In the same config file as the 2 previous?
  

Configuring MQTTSubscribe can be a bit daunting, so just shout with any additional questions.

rich

I would bet I need to get mosquitto running properly before I start configuring MQTTSubscribe?

I installed mosquitto in the same Ubuntu 20 VM were WeeWX is running.

I loaded mosquito from the Ubuntu 20 deb repo with 'sudo apt install mosquitto'

I used the example mosquitto.conf file (/usr/share/doc/mosquitto/examples/mosquitto.conf) to create a basic mosquitto.conf.

There is a README file in /etc/mosquitto/conf.d which says:

"Any files placed in this directory that have a .conf ending will be loaded as

config files by the broker. Use this to make your local config."
I believe this means that /etc/mosquitto/conf.d is the correct place for the mosquitto.conf file?

Right now, I'm trying to get mosquitto to autostart as a daemon.  But it's not starting.

When I use the command 'sudo update-rc.d mosquitto defaults' it creates a bunch of files named K01mosquito in the /etc/rc.0...../etc/rc.6 directories.

I looked inside these files and it has the wrong location for mosquitto.conf file.

See excerpt:

start)

        if init_is_upstart; then

            exit 1

        fi

        log_daemon_msg "Starting network daemon:" "mosquitto"

        if start-stop-daemon --start --quiet --oknodo --background  --make-pidfile --pidfile ${PIDFILE} --exec ${DAEMON} -- -c /etc/mosquitto/mosquitto.conf ; then

            log_end_msg 0

        else

            log_end_msg 1

        fi

        ;;

Why did the K01mosquitto files get created with the wrong .conf file location in them?

How do I fix that file location without manually editing all those auto-created /etc/rc.x/K01mosquitto files?

Thanks,

Eric

[Graham Eddy]

On 12 May 2021, at 1:22 pm, Eric Koester <eric.k...@gmail.com> wrote:

I would bet I need to get mosquitto running properly before I start configuring MQTTSubscribe?

yes, it is pointless looking at a mosquitto apps unless mosquitto itself is working

I used the example mosquitto.conf file (/usr/share/doc/mosquitto/examples/mosquitto.conf) to create a basic mosquitto.conf.

There is a README file in /etc/mosquitto/conf.d which says:

"Any files placed in this directory that have a .conf ending will be loaded as

config files by the broker. Use this to make your local config."
I believe this means that /etc/mosquitto/conf.d is the correct place for the mosquitto.conf file?

no: the default config is all in /etc/mosquitto/mosquitto.conf. very probably this is identical to the reference copy in /usr/share/... (conf.d/ is provided if you are going to split your config into multiple files - don't do this unless you have a sophisticated need and know why you are doing it)

summary: /etc/mosquitto/mosquitto.conf is correct file. do your edits in that

[Eric Koester]

I'm working around the location of the mosquito.conf file by moving it to where all the init.d files are looking for it - /etc/mosquito/mosquitto.conf.

After doing that, the service starts without errors.  See:

weewx@Ubuntu20-WEEWX:/etc/rc0.d$ systemctl status mosquitto.service

● mosquitto.service - Mosquitto MQTT Broker

     Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)

     Active: active (running) since Tue 2021-05-11 22:25:14 CDT; 7min ago

       Docs: man:mosquitto.conf(5)

             man:mosquitto(8)

    Process: 7126 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto (code=exited, status=0/SUCCESS)

    Process: 7127 ExecStartPre=/bin/chown mosquitto: /var/log/mosquitto (code=exited, status=0/SUCCESS)

   Main PID: 7128 (mosquitto)

      Tasks: 1 (limit: 2310)

     Memory: 2.2M

     CGroup: /system.slice/mosquitto.service

             └─7128 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

weewx@Ubuntu20-WEEWX:/etc/rc0.d$ sudo systemctl status mosquitto.service

● mosquitto.service - Mosquitto MQTT Broker

     Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)

     Active: active (running) since Tue 2021-05-11 22:25:14 CDT; 15min ago

       Docs: man:mosquitto.conf(5)

             man:mosquitto(8)

    Process: 7126 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto (code=exited, status=0/SUCCESS)

    Process: 7127 ExecStartPre=/bin/chown mosquitto: /var/log/mosquitto (code=exited, status=0/SUCCESS)

   Main PID: 7128 (mosquitto)

      Tasks: 1 (limit: 2310)

     Memory: 1.7M

     CGroup: /system.slice/mosquitto.service

             └─7128 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf

Strangely, I do NOT see a /var/run/mosquitto.pid file when it's running.

Any idea why?

[Eric Koester]

Since I called it out, I expected a pid file to be created, but it isn't.

Here's my current /etc/mosquito/mosquito.conf file:

# A full description of the configuration file is at

# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

protocol mqtt

port 1883

allow_anonymous true

pid_file /var/run/mosquitto.pid

persistence true

persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

[Graham Eddy]

mosquitto doesn’t need a pidfile - pidfiles are legacy from init.d (my times!)

[Eric Koester]

I see I mistyped mosquitto in at least one place above.  

The /etc/mosquitto directory is spelled correctly in my Ubuntu 20 machine.

Ok, on the pid file.  

The version of mosquitto in the Ubuntu 20 deb repo still has provision for pid files, so its confusing.

It appears that the mosquitto install is properly starting as a daemon (I see it in the process table in TOP) and running without errors in the /var/log/mosquitto/mosquitto.log, so I think I'm ready to move on to configuring MQTTSubscribe.

On Tuesday, May 4, 2021 at 3:52:59 PM UTC-5 bell...@gmail.com wrote:

A few additional things to consider.

From, https://tasmota.github.io/docs/BME280/, your json data is ‘nested’. Meaning the incoming names in MQTTSubscribe will be BME280_Pressure, BME280_Temperature, and BME280_Humidity. 

What config file do you enter these incoming names into?

 

You will want to use the ‘ignore’ option for PressureUnit and TempUnit.

What config file do you put the ignore option into?

 

Due to the way MQTTSubscribe handles date/time data, the Time field is a bit more interesting. I would also ‘ignore’ it. This just means that MQTTSubscribe will not try to check that the data is in the time interval being processed by WeeWX. 

What syntax do you use to tell it to ignore the date/time data?
In the same config file as the 2 previous?
  

Configuring MQTTSubscribe can be a bit daunting, so just shout with any additional questions.

rich

If there are any example configurations detailed online, that would give me something to copy.

Making progress...

[Greg Troxel]

Eric Koester <eric.k...@gmail.com> writes:

> I see I mistyped mosquitto in at least one place above.
> The /etc/mosquitto directory is spelled correctly in my Ubuntu 20 machine.
>
> Ok, on the pid file.
> The version of mosquitto in the Ubuntu 20 deb repo still has provision for
> pid files, so its confusing.

mosquitto has support for pid files, and many systems use them. Whether
they are normal and the right thing, or last year's plan depends on how
your system deals with init things. However this is unlikely to make
things work or not work, just ma make the init system unhappy about
statusing and stopping mosquitto.

> It appears that the mosquitto install is properly starting as a daemon (I
> see it in the process table in TOP) and running without errors in the
> /var/log/mosquitto/mosquitto.log, so I think I'm ready to move on to
> configuring MQTTSubscribe.

No, you are ready to use mosquitto_sub on the machine you want to run
MQTTSubscribe and see if you are seeing the data from the command-line
client. Pause to reconfigure mosquitto to listen beyond localhost if
you need to, to figure out what you are doing about 1883 vs 8883/tls,
and acls. Any time you can test at an intermedidate point, you make
things simpler to figure out.

You can also use mosquitto_pub on the machine that is supposed to inject
mqtt messsages.

Note that mosquitto silently drops topic writes that are not allowed by
the acl.

[bell...@gmail.com]

As Greg said, make sure your MQTT infrastructure is up and running correctly. Since you installed your own broker, a first check is to use mosquitto_sub and mosquitto_pub to a test topic. Once that is working, use mosquitto_sub to subscribe to the broker and topic(s) that you want MQTTSubscribe to subscribe to. This will also provide you with the MQTT message. The actual message will be useful as you configure WeeWX/MQTTSubscribe.

Next read https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki. This will outline the install steps and point you to https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring, which has the information on configuring WeeWX/MQTTSubscribe. This page will also provide you with links to configuration examples by payload ‘type’.

rich

[Eric Koester]

For those following along, I discovered that the mosquitto_pub & mosquitto_sub clients were automatically installed when I installed mosquitto into Ubuntu.  Here was the tip-off:

weewx@Ubuntu20-WEEWX:~$ sudo apt install mosquitto-clients

Reading package lists... Done

Building dependency tree       

Reading state information... Done

mosquitto-clients is already the newest version (1.6.12-1).

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I found some Youtube videos by Steve Cope which show examples of using the commands.

https://youtu.be/J4pqv9__uzE

He mentions using the debug switch (-d) so you can see that the commands are doing something - very useful!

Running mosquitto_pub in one terminal window and mosquitto_sub in another is showing feedback of success!

weewx@Ubuntu20-WEEWX:~$ mosquitto_pub -h 192.168.7.22 -p 1883 -t sensors/temperature -m "1266193804 32" -d

Client mosq-6o6U1MqsMVovfxfZta sending CONNECT

Client mosq-6o6U1MqsMVovfxfZta received CONNACK (0)

Client mosq-6o6U1MqsMVovfxfZta sending PUBLISH (d0, q0, r0, m1, 'sensors/temperature', ... (13 bytes))

Client mosq-6o6U1MqsMVovfxfZta sending DISCONNECT

weewx@Ubuntu20-WEEWX:/etc/mosquitto$ mosquitto_sub -h 192.168.7.22 -p 1883 -t sensors/temperature -d

Client mosq-VJoHFtTvE0io4OBXfe sending CONNECT

Client mosq-VJoHFtTvE0io4OBXfe received CONNACK (0)

Client mosq-VJoHFtTvE0io4OBXfe sending SUBSCRIBE (Mid: 1, Topic: sensors/temperature, QoS: 0, Options: 0x00)

Client mosq-VJoHFtTvE0io4OBXfe received SUBACK

Subscribed (mid: 1): 0

Client mosq-VJoHFtTvE0io4OBXfe received PUBLISH (d0, q0, r0, m0, 'sensors/temperature', ... (13 bytes))

1266193804 32

Client mosq-VJoHFtTvE0io4OBXfe sending PINGREQ

Client mosq-VJoHFtTvE0io4OBXfe received PINGRESP

[Eric Koester]

I've got a BMP280 sensor (only 2 internal sensors) connected to an ESP-12F module, running Tasmota firmware.

The example I'm following is a BME280 which has 3 internal sensors.

https://tasmota.github.io/docs/BME280/

Rich Bell mentioned that the BME280 (and BMP280) data is json and nested and that the data would come through as BMP280_Temperature, BMP280_Pressure.

I roughly configured the MQTT settings in Tasmota and you can see it's made connection with the mosquitto broker.
section of /var/log/mosquitto/mosquitto.log file:

1620871934: New connection from 192.168.7.132 on port 1883.

1620871934: New client connected from 192.168.7.132 as ESP-12F_1 (p2, c1, k30, u'ESP-12F_USER').

1620872759: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.

I'm not clear what I should set the Topic and Full Topic fields to in the Tasmota MQTT screen.

  

[Eric Koester]

Maybe this line from the Tasmota Console (log) is a clue?

21:54:27.154 MQT: sensors/BMP280/SENSOR = {"Time":"2021-05-12T21:54:27","BMP280":{"Temperature":22.0,"Pressure":990.8},"PressureUnit":"hPa","TempUnit":"C"}

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/JOBL7t-m5M0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/171227e8-3080-4a59-84d3-a26b078c669an%40googlegroups.com.

[Eric Koester]

Here's what I've got in my weewx.conf file thus far.  

Does this look close to correct, when you compare it to the MQTT message from the Tasmota log?

21:54:27.154 MQT: sensors/BMP280/SENSOR = {"Time":"2021-05-12T21:54:27","BMP280":{"Temperature":22.0,"Pressure":990.8},"PressureUnit":"hPa","TempUnit":"C"}

############################################################################

# Options for 'MQTTSubscribeService'

[MQTTSubscribeService]

    # This section is for the MQTTSubscribe service.

    

    # Turn the service on and off.

    # Default is: true

    # Only used by the service.

    enable = false

    

    # The MQTT server.

    # Default is localhost.

    host = localhost

    

    # The port to connect to.

    # Default is 1883.

    port = 1883

    

    # Maximum period in seconds allowed between communications with the broker.

    # Default is 60.

    keepalive = 60

    

    # username for broker authentication.

    # Default is None.

    username = None

    

    # password for broker authentication.

    # Default is None.

    password = None

    

    # The binding, loop or archive.

    # Default is: loop

    # Only used by the service.

    binding = loop

    

    # The message handler to use

    [[message_callback]]

        # The format of the MQTT payload.

        # Currently support: individual, json, keyword

        # Must be specified.

        type = json

    

        # When the json is nested, the delimiter between the hierarchies.

        # Default is _.

        flatten_delimiter = "_"

    

    # The topics to subscribe to.

    [[topics]]

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # Default is: US

        unit_system = METRIC

        

        [[[first/topic]]]

            # The incoming field name from MQTT.

            [[[[Time]]]]

                # left side is the name from MQTT.

                # right side is the WeeWX name.

                Time = dateTime           

            

        [[[second/topic]]]      

            # The incoming field name from MQTT.          

            [[[[BME280_Temperature]]]]

                # left side is the name from MQTT.

                # right side is the WeeWX name.

                Temperature = extraTemp1

            [[[[BME280_Pressure]]]]

                # left side is the name from MQTT.

                # right side is the WeeWX name.

                Pressure = barometer

                

        [[[third/topic]]]

            # The incoming field name from MQTT.

            [[[[PressureUnit]]]]

                # left side is the name from MQTT.

                # right side is the WeeWX name.

                PressureUnit = ??

                

        [[[fourth/topic]]]

            # The incoming field name from MQTT.

            [[[[TemperatureUnit]]]]

                # left side is the name from MQTT.

                # right side is the WeeWX name.

                TempUnit = ??

[Eric Koester]

I just saw evidence from the mosquitto_sub command, that the BMP280 MQTT data is making it into the mosquitto broker!

More progress!
I'm still not sure what the Topic and Full Topic fields should be in that Tasmota MQTT config screen.

weewx@Ubuntu20-WEEWX:~$ mosquitto_sub -h 192.168.7.22 -p 1883 -t sensors/BMP280/SENSOR -d

Client mosq-57pl5MGgj73xs69ThZ sending CONNECT

Client mosq-57pl5MGgj73xs69ThZ received CONNACK (0)

Client mosq-57pl5MGgj73xs69ThZ sending SUBSCRIBE (Mid: 1, Topic: sensors/BMP280/SENSOR, QoS: 0, Options: 0x00)

Client mosq-57pl5MGgj73xs69ThZ received SUBACK

Subscribed (mid: 1): 0

Client mosq-57pl5MGgj73xs69ThZ sending PINGREQ

Client mosq-57pl5MGgj73xs69ThZ received PINGRESP

Client mosq-57pl5MGgj73xs69ThZ sending PINGREQ

Client mosq-57pl5MGgj73xs69ThZ received PINGRESP

Client mosq-57pl5MGgj73xs69ThZ sending PINGREQ

Client mosq-57pl5MGgj73xs69ThZ received PINGRESP

Client mosq-57pl5MGgj73xs69ThZ received PUBLISH (d0, q0, r0, m0, 'sensors/BMP280/SENSOR', ... (113 bytes))

{"Time":"2021-05-12T22:44:28","BMP280":{"Temperature":22.0,"Pressure":990.9},"PressureUnit":"hPa","TempUnit":"C"}

[Jozef Smolders]

you can try something like this:

        # When the json is nested, the delimiter between the hierarchies.

        # Default is _.

        flatten_delimiter = "_"    

    # The topics to subscribe to.

    [[topics]]

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # Default is: US

        unit_system = METRIC

        # Even if the payload has a datetime, ignore it and use the server datetime.

        # Default is False.

        use_server_datetime = True

        # When True, the MQTT datetime will be not be checked that is greater than the last packet processed.

        # Default is False.

        # Only used by the service.

        ignore_start_time = True

        # When the True, the MQTT data will continue to be processed even if its datetime is greater than the packet's datetime.

        # Default is False.

        # Only used by the service.

        ignore_end_time = True

        

        [[[sensors/BMP280/SENSOR]]]

            [[[[Time]]]]

                # True if the incoming data should not be processed into WeeWX.

                # Valid values: True, False

                # Default is False

                ignore = True

            [[[[BMP280_Temperature]]]]

            name = inTemp

            [[[[BMP280_Pressure]]]]

            name = barometer

            [[[[PressureUnit]]]]

                ignore = True

            [[[[TempUnit]]]]

                ignore = True

Op donderdag 13 mei 2021 om 05:32:15 UTC+2 schreef eric.k...@gmail.com:

[Eric Koester]

I've been looking at Rich Bell's nested json example here:
https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/json-example

He shows a first topic, second topic, third topic, etc.

If you include the time, I think this BMP280 has 5 topics?  (Time, Temperature, Pressure, PressureUnit, TempUnit)

Here's what I've got now: in my weewx.conf file:

    # The message handler to use

    [[message_callback]]

        # The format of the MQTT payload.

        # Currently support: individual, json, keyword

        # Must be specified.

        type = json

    

        # When the json is nested, the delimiter between the hierarchies.

        # Default is _.

        flatten_delimiter = "_"

    

    # The topics to subscribe to.

    [[topics]]

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # Default is: US

        unit_system = METRIC

  

        use_server_datetime = True

        ignore_start_time = True

        ignore_end_time = True

        

        [[[first/topic]]]

            # The incoming field name from MQTT.

            [[[[Time]]]]

                ignore = true         

            

        [[[second/topic]]]                

            [[[[BME280_Temperature]]]]

                # The WeeWX name.

                # Default is the name from MQTT.

                name = appTemp1

                units = degree_C  

            [[[[BME280_Pressure]]]]

                # The WeeWX name.

                # Default is the name from MQTT.

                name = barometer

                units = hPa

                

        [[[third/topic]]]

            # The incoming field name from MQTT.

            [[[[PressureUnit]]]]

                ignore = true

                

        [[[fourth/topic]]]

            # The incoming field name from MQTT.

            [[[[TemperatureUnit]]]]

                ignore = true

[bell...@gmail.com]

Using this data point that you posted earlier, I formatted it a bit to better show the json structure.

21:54:27.154 MQT: sensors/BMP280/SENSOR = 

{

  "Time":"2021-05-12T21:54:27",

  " BMP280":

    {

      "Temperature":22.0,

      "Pressure":990.8

    },

  "PressureUnit":"hPa",

  "TempUnit":"C"

}

You’ve got one topic, ‘sensors/BMP280/SENSOR’ that is publishing json data.

You’ve got four top level fields, ‘Time’, ‘BMP280’, ‘PressureUnit’, and ‘TempUnit’.

‘BMP280’ is an object consisting of two fields, ‘ Temperature’, and ‘Pressure’. I am calling this ‘nested json’. This will result in 2 fields named ‘BMP280_Temperature’ and ‘BMP280_Pressure’.

So, your configuration should be something like this.

# The message handler to use

    [[message_callback]]

        # The format of the MQTT payload.

        # Currently support: individual, json, keyword

        # Must be specified.

        type = json

    

    # The topics to subscribe to.

    [[topics]]

        # Units for MQTT payloads without unit value.

        # Valid values: US, METRIC, METRICWX

        # Default is: US

        unit_system = METRIC

        [[[sensors/BMP280/SENSOR]]]

            [[[[Time]]]]

                ignore = true         

            

            [[[[BMP280_Temperature]]]]

                # The WeeWX name.

                # Default is the name from MQTT.

                name = appTemp1

            [[[[BMP280_Pressure]]]]

                # The WeeWX name.

                # Default is the name from MQTT.

                name = barometer

                

            # The incoming field name from MQTT.

            [[[[PressureUnit]]]]

                ignore = true

                

            # The incoming field name from MQTT.

            [[[[TemperatureUnit]]]]

                ignore = true

rich

[Eric Koester]

THANKS RICH!!

It really helped to see my actual JSON message get translated into the weewx.conf file format!

WeeWX got it's first barometer reading shortly after I made the edits and retstarted weewx at 2:59pm today!

Quick question:

Since I removed the line "units = hPa" from the confg file, how does weewx know that my pressure sensor reading is hPa rather than kPa?

An educated guess, based on the magnitude?

THANKS ALL!

With a barometer reading, my WeeWX setup is now complete!!

Eric

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/JOBL7t-m5M0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/472f3a4b-26a8-462a-be77-5357fff6a989n%40googlegroups.com.

[bell...@gmail.com]

Eric,

There are ‘default’ units for each WeeWX unit system. For the METRIC unit system the default for altimeter, barometer, and pressure is mbar/hPa. For additional information see, http://www.weewx.com/docs/customizing.htm#units

rich