WeeWX in an RV?

[Stefan Gliessmann]

Dear all -

I was googling this topic without any results. So, I came here to see, if anybody did this already.

Since ever I have a weewx installation running at home, I would like to built a second one in my RV with probably just temps in/out, humidity in/out and air pressure. The RV has 4G/5G internet connection and plenty of power to run a RPi ...

Any experiences with updating the station locations automatically in weewx.conf? Anything else seems to be straight forward ...

Cheers,

Stefan

[p q]

Why not use the same one and send the temp/rH via MQTT to your main system, since you have connectivity. You can use one of the ExtraTemps and there's probably something suitable for rH.

--
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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/97dea70f-9a2e-422d-a25b-924011308c35n%40googlegroups.com.

--

Peter Quinn
(415)794-2264

[vince]

On Saturday, July 29, 2023 at 10:49:14 AM UTC-7 Stefan Gliessmann wrote:

Any experiences with updating the station locations automatically in weewx.conf? Anything else seems to be straight forward ...

Why do you need to update the location at all ?   What is your goal for displaying the data ?   Do you need to upload somewhere and/or have a db of historical data (ie, do you really even need weewx) ?   And of course what's your budget ?

Picking a random Ecowitt product it's under a $50 thing if you just want a small display and a sensor or two with no internet required...

(https://shop.ecowitt.com/products/wn2810)

 

[Stefan Gliessmann]

There is no real reason why other then having historical record of weather where I was …

I am thinking of the Ecowitt GW-1100 with an external 3-in-1 sensor or this one 

https://www.amazon.de/dp/B06X3YDSVS?psc=1&smid=A29AHYTNE2R6PE&ref_=chk_typ_imgToDp which should be compatible with the Ecowitt infrastructure.

When updating the location, forecasts should be also updated within skins like Belchertown.

--
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/Fwd1BvCfCoM/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/d033aa60-76a0-44e0-9009-3398ac0d65c4n%40googlegroups.com.

[Stefan Gliessmann]

That would work. But I would miss out on the location and elevation data … I would like to include location in a database …

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/Fwd1BvCfCoM/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/CAA1SM22tJ81-cEEcFrpK6yD%2BOoqjnLB7CsJbvr8HRnZ%2BPMdo6w%40mail.gmail.com.

[Rainer Lang]

You can get a GW1100 which comes already with an inbuilt indoor T/H sensor, a WH32 outdoor for the outdoor T/H and maybe, if you need more, another WH31 extra T/H sensor.
An external 3-in-1 sensor doesn't exist in the Ecowitt universe. Indoor, yes, but a GW1100 cannot receive it.
And then run weewx on a RPi with the Ecowitt Gateway driver (aka GW1000 driver).

As you seem to be German (or from a German speaking country), I recommend you read the very elaborated Ecowitt Weather station WiKi at https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen

There you find all available Ecowitt sensors, their combination possibilities and all available consoles/gateways

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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CACXWM9ROvh-bmCSMYctgS8J5%3Db5_yes-_0%2BV7ANgSyJp7YzNrA%40mail.gmail.com.

[Rainer Lang]

your location data you can get out of weewx 😉

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CACXWM9Q7vSQ%3DvyPm0Uvpw9t7u0Uz3ajzuvSTNYKC3OimW-0-6w%40mail.gmail.com.

[vince]

On Saturday, July 29, 2023 at 1:11:25 PM UTC-7 Stefan Gliessmann wrote:

That would work. But I would miss out on the location and elevation data … I would like to include location in a database …

Sure. Get a GPS module for your pi and write a little script to seed a custom field in the db.   Shouldn't be a big deal.  Just write to a secondary sqlite db.

 

[Cameron D]

This would be my suggestion as well.  Certainly use a dedicated DB for the task, then populate it according to the effort you want to put into it.

Options would be:

• custom GPS unit along the lines Vince suggested
• use a normal in-car GPS unit that records your tracks and download/export data each day.  I combine my car and walking gps tracks for geotagging photos.
• manually enter data once a day

When I do long trips, I often take a simple handheld temp/RH logger that I download occasionally - every few days.

I also have a second table with one row per day, where I manually enter comments about where the device was located and anything unusual that might have influenced the results.  Probably less necessary in an RV with fixed locations, but my logger might end up left inside the tent, outside the tent, or left inside the car on different days.  This table could also double as a more general diary.

[Stefan Gliessmann]

After running into major issues with my LTE router in my RV, weewx and Belchertown w/ MQTT are up and running :)

Check it out here: https://t.ly/4icFe

My RV router is actually a serious professional LTE router which can provide GPS data, too (once I have a GPs receiver installed).

Now, I still have to figure out how to push the GPS data into weewx db and have weewx use it for the weather forecasts using aeris within the Belchertown skin.

Since I have MQTT already working and my router can send the GPS data as MQTT packages, maybe that is a way to do so.

In weewx.conf the long, latitude and altitude are specified. Is there a way to not update these in the weewx.conf, but have them read from the db and considered accordingly?

Thanks for brainstorming this with me ;)

TIA,

Stefan

[Tom Keffer]

One way of doing this...

Station altitude, latitude, and longitude are always obtained from an instance of StationInfo, held in the engine. From this, various views are constructed, including what's used as a tag, such as $station.altitude.

So, with every new archive record you could replace that instance with a fresh instance, created in a WeeWX service, using updated values. The instance is available as engine.stn_info in the service.

How does your service get its information? One way would be to add new observation types altitude, latitude, and longitude to the archive record. Then your new service can get the values from there.

If you also want values in the database, add altitude,  longitude, and latitude to the schema and they will automatically be populated if the archive record holds matching types.

That's off the top of my head. It's a nice approach because it does not involve modifying any base weewx code. But, I'm sure I've missed something...

-tk

--

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 weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/c0a89ba0-e981-4e58-8a3b-9412bbd0b1c4n%40googlegroups.com.

[Stefan Gliessmann]

Wow - thanks, Tom!

That actually sound pretty straight forward and almost too easy ;)

Once I have the GPS receiver hooked up to my LTE router; I will try it out!

😇

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/Fwd1BvCfCoM/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/CAPq0zECNoy6YbZTHN7DvwhN0n0SEJF5AR4GYEWEjf0hdkomcAA%40mail.gmail.com.

[Stefan Gliessmann]

Well - I was successful in forwarding the RV's GPS data per MQTT to the Belchertown skin.

It receives the coordinates, but it does not know what to do with it (e.g. "Data received Invalid date").

Where would I need to define what values these are and how to store them in the weewx.sdb?

Thank you for any input! :)

Cheers,

Stefan

[Stefan Gliessmann]

This is what I see in MQTT for the GPS data:

[{"dateTime":"1692897570", "gpsLat":"52.152496"},{"dateTime":"1692897570", "gpsLong":"9.929346"}]

versus 

{"dateTime": "1692897612.0", "inTemp_C": "30.1", "outTemp_C": "27.5", "outHumidity": "54.0", "pressure_mbar": "1001.3000000000001", "relbarometer": "1001.3", "wh31_ch1_batt": "0.0", "wh31_ch1_sig": "4.0", "inHumidity": "49.0", "altimeter_mbar": "1004.9493958235101", "barometer_mbar": "1004.7053486054396", "cloudbase_meter": "1295.8252688165874", "dewpoint_C": "17.347230252723698", "heatindex_C": "28.22227943194455", "humidex_C": "33.03157722271784", "inDewpoint_C": "18.191750223011855", "rainRate_cm_per_hour": "0.0", "usUnits": "16.0"}

I just noticed the [ ... ], but still MQTT in Belchertown needs to be explained what these values are. Where would I need to do that?

[Karen K]

You can define new observation types in /usr/share/weewx/extensions.py like this:

import weewx.units

for group in weewx.units.std_groups:

    weewx.units.std_groups[group].setdefault('group_coordinate','degree_compass')

weewx.units.obs_group_dict.setdefault('gpsLat','group_coordinate')

weewx.units.obs_group_dict.setdefault('gpsLong','group_coordinate')

[Stefan Gliessmann]

Thank you for providing the extensions.py code, Karen K!

You really rock!!!

I placed it @ /usr/share/weewx/

with this I added new observations. 

(Check)

I also added the database columns with 

sudo wee_database --add-column=gpsLat

sudo wee_database --add-column=gpsLong

(Check)

However, they are empty with NULL

and in weewx.conf I added:

    [[MQTT]]
     server_url = mqtt://xyz:xyz...@teffi71.spdns.de:1883/
     topic = RV
     unit_system = METRIC
     binding = loop, archive
     log_success = true
      [[[inputs]]]
       [[[[gpsLat]]]]
         name = gpsLat
#        units = mm_per_hour
       [[[[gpsLong]]]]
         name = gpsLong

(Is adding this to weewx.conf needed?)

Whenever the gps coordinates are sent, the Belchertown MQTT status line says:

Connected to weather station live. Data received Invalid date

Looking in the Chrome Inspect console I can see:

MQTT: [{"dateTime":"1693128694.0","gpsLat":"52.152435"},{"dateTime":"1693128694.0","gpsLong":"9.929356"}] 

MQTT: [{"dateTime":"1693128696.0","gpsLat":"52.152435"},{"dateTime":"1693128696.0","gpsLong":"9.929356"}]  

MQTT: [{"dateTime":"1693128698.0","gpsLat":"52.152435"},{"dateTime":"1693128698.0","gpsLong":"9.929356"}]  

MQTT: {"dateTime": "1693128703.0", "inTemp_C": "20.2", "outTemp_C": "20.500000000000004", "outHumidity": "66.0", "pressure_mbar": "998.3", "relbarometer": "998.3", "wh31_ch1_batt": "0.0", "wh31_ch1_sig": "4.0", "inHumidity": "60.0", "altimeter_mbar": "1001.9404121257783", "barometer_mbar": "1001.7762197264383", "cloudbase_meter": "849.858055043151", "dewpoint_C": "13.923820763390072", "heatindex_C": "20.328888888888894", "humidex_C": "23.820824059901074", "inDewpoint_C": "12.180722362154029", "rainRate_cm_per_hour": "0.0", "usUnits": "16.0"} 

MQTT: [{"dateTime":"1693128700.0","gpsLat":"52.152435"},{"dateTime":"1693128700.0","gpsLong":"9.929356"}]  

MQTT: [{"dateTime":"1693128702.0","gpsLat":"52.152435"},{"dateTime":"1693128702.0","gpsLong":"9.929356"}] 

MQTT: [{"dateTime":"1693128704.0","gpsLat":"52.152435"},{"dateTime":"1693128704.0","gpsLong":"9.929356"}] 

MQTT: {"dateTime": "1693128708.0", "inTemp_C": "20.2", "outTemp_C": "20.500000000000004", "outHumidity": "66.0", "pressure_mbar": "998.3", "relbarometer": "998.3", "wh31_ch1_batt": "0.0", "wh31_ch1_sig": "4.0", "inHumidity": "60.0", "altimeter_mbar": "1001.9404121257783", "barometer_mbar": "1001.7762197264383", "cloudbase_meter": "849.858055043151", "dewpoint_C": "13.923820763390072", "heatindex_C": "20.328888888888894", "humidex_C": "23.820824059901074", "inDewpoint_C": "12.180722362154029", "rainRate_cm_per_hour": "0.0", "usUnits": "16.0"}

What do I miss? What may I have done wrongly?

[vince]

A very old thread here with somebody who previously had that error pointed to the MQTT topic being subscribed to as the error.   They were subscribing to sometopic/# when they should have subscribed to sometopic/someitem

What topic are you subscribing to for your data ?

[Stefan Gliessmann]

Thank you for the hint!

The MQTT topic under which I publish the weather data and the gps coordinates is RV.

The weather data is sent and received well via this section:

    [[MQTT]]
     server_url = mqtt://xyz:xyz...@teffi71.spdns.de:1883/
     topic = RV
     unit_system = METRIC
     binding = loop, archive
     log_success = true
      [[[inputs]]]
       [[[[gpsLat]]]]
         name = gpsLat
#        units = mm_per_hour
       [[[[gpsLong]]]]
         name = gpsLong

The GPS data is sent via the Router/GPS via Modbus per MQTT to the same MQTT broker as above:

If I change the Topic here anything else then RV/loop, Belchertown is no longer receiving the gps coordinates ... (as seen in the inspector/console of Chrome).

I noticed when observing the topic RV in MQTT Explorer:

- each value of the weather data is listed below the {...} statement,

- but for the gps data it isn't.

the gps data is only listed with "square brackets". I do not know from where these are originating as I have not specified them in the JSON format.
Are those "square brackets" the trouble makers?

TIA!

On Sun, Aug 27, 2023 at 5:33 PM vince <vince...@gmail.com> wrote:

A very old thread here with somebody who previously had that error pointed to the MQTT topic being subscribed to as the error.   They were subscribing to sometopic/# when they should have subscribed to sometopic/someitem

What topic are you subscribing to for your data ?

--

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/Fwd1BvCfCoM/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/b77d60fa-3f6b-42b5-808d-eb115ea40c2fn%40googlegroups.com.

[vince]

We'd have to see your code to see what you are publishing.

Your MQTT log looks very odd and likely needs some tweaking

MQTT: [{"dateTime":"1693128700.0","gpsLat":"52.152435"},{"dateTime":"1693128700.0","gpsLong":"9.929356"}]  

I'd expect something like {"dateTime":"1233456", "gpsLat":"52.1234", "gpsLong": "9.987"} for a more typical set of JSON to publish.   You want one element (not in an array) with three items therein - dateTime/lat/lon.

[Stefan Gliessmann]

Which code do you refer to?

This is what I specified in the GPS/Router to push via MQTT to my broker ...

[Stefan Gliessmann]

I asked in the community forum for my router and I was told that this is the only way they can currently forward data via MQTT.

A future firmware release shall allow more formatting.

I might now play around with this https://github.com/mrtncls/mqtt-translator to get the MQTT payload from an array in one single statement ...

Anybody used the MQTT Translator for this purpose?

[vince]

(sorry - ignore the earlier truncated post)

I cooked up a bash script that subscribes, calls a python script to reformat, then publishes.   The bash script sleeps a second between loops to not eat up your cpu.   You 'should' be able to change the variables in the bash script to match your configuration pretty easily...

This subscribes to ORIGINAL_TOPIC and publishes to FINAL_TOPIC in the bash script.

To test:

• open a bash window and subscribe to the FINAL_TOPIC
• open a second window and run the bash script which will listen/reformat/publish
• if you're not querying your gps currently, open a third window and publish to the ORIGINAL_TOPIC ala

            mosquitto_pub -h 192.168.1.171 -t RV/original -m '[{"dateTime":"1693128700.0","gpsLat":"52.152435"},{"dateTime":"1693128700.0","gpsLong":"9.929356"}]'

What you should see in window1 that is subscribing is output ala:

{"dateTime": "1693128700.0", "gpsLat": "52.152435", "gpsLong": "9.929356"}

That kind of data should be ok to subscribe to in weewx for your lat/lon data....

#---- reformat_mqtt.bash ----

#!/bin/bash
#
# ip address of MQTT broker
BROKER="192.168.1.171"

ORIGINAL_TOPIC="RV/original"
FINAL_TOPIC="RV/final"

while true; do

  # subscribe to a topic
  # run the python script to reformat to stdout
  # publish to a final topic

  mosquitto_sub -C 1 -h ${BROKER} -t ${ORIGINAL_TOPIC} \
    | python3 reformat_mqtt.py \
    | mosquitto_pub --stdin-line -h ${BROKER} -t ${FINAL_TOPIC}

  # sleep a bit to not eat up your cpu
  sleep 1

done

#---- reformat_mqtt.py -----

#
# this reformats the GPS information
# to a more normal looking output
#

# it assumes your input data is always in the same order and always complete
# ala: [{"dateTime":"1693128700.0","gpsLat":"52.152435"},{"dateTime":"1693128700.0","gpsLong":"9.929356"}]

import json
import sys
for line in sys.stdin:
    jsondata = json.loads(line)
    reorganized_data = {}
    reorganized_data['dateTime'] = jsondata[0]['dateTime']
    reorganized_data['gpsLat']   = jsondata[0]['gpsLat']
    reorganized_data['gpsLong']  = jsondata[1]['gpsLong']
    print(json.dumps(reorganized_data))

[Stefan Gliessmann]

Dear Vince,

thank you very much for providing the scripts! I really do appreciate!

However, last Tuesday I changed my ISP. Good think - it is 1 Gbps! And my challenge was that it is IPv6 and I had to learn very quickly that port forwarding with IPv6 is completely different to IPv4, and even more particular DDNS with IPv6.

But I am happy to report that my server is back online rv.sgplex.de :)

As I will be on vacation in Spain the next few weeks, I will place your scripts in action!

Thanks again for providing them!

Cheers

[vince]

Yes.  ipv6 is an adventure.  I tried to turn it on for my home LAN and DNS was a big problem until I figured out that I just needed to always use "hostname.local" for the LAN DNS and it would work.  Unfortunately it also seemed to break my pihole ad-blocking so I turned ipv6 back off here after a few day test.

I like the clock on your About page too!

[Stefan Gliessmann]

Vince, thank you again for the scripts ... once I figured out that my MQTT requires  user & password, it works now ...

seems that I still have to do something with the units for the GPS coordinates ...

[Stefan Gliessmann]

The clock in my about page is actually from https://github.com/roe-dl/websocket-clock-js/commits?author=roe-dl aka Karen K in this group!

She did a lot of work to use German weather data (DWD) with the Belchertown skin.

Check out her work on her PWS page https://www.woellsdorf-wetter.de/

[Stefan Gliessmann]

This is an awesome group!

Without your help of so many folks, I would not have achieved what I have so far ...

Still need to do more to pass the coordinates to Belchertown skin forecasts and weather warnings ...

But I am getting there now (I hope) ...

Thank you all again for your help!

[Stefan Gliessmann]

What is the right unit for longitude and latitude?

They should be degrees, but other then for temperature or compass I couldn't find any other ...

[DR]

Is your reported cloud base a calculated value, or do you have a fancy LIDAR or something to get that info?

And same for percentage of cloud cover, 19% seems very precise.   Is that just picked off the range of cloud cover or is there some way you can measure that value?

Dale

--

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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/df8aac81-545b-4439-b507-0c52c9142628n%40googlegroups.com.

[vince]

Karen answered your question previously - https://groups.google.com/g/weewx-user/c/Fwd1BvCfCoM/m/NAuZqAfTAAAJ

[Stefan Gliessmann]

Thank you for reminding me of Karen's input ...

Nevertheless, I am unable to have units for the coordinates displayed in Belchertown skin.

Furthermore, longitude and latitude are first invalid observation

until a MQTT GPS packet is delivered. Then in turns into

Any ideas why?

P.S.: I changed from gpsLat to latitude and gpsLong to longitude ...

[Sheldon Herold]

Bin bald zuhause.
-Von meinem Garmin-Gerät gesen 

--

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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/75fe0f45-0523-452c-b5cc-325007ca5929n%40googlegroups.com.

[Karen K]

You could set

degree_compass = " °"

in section "Labels" of section "Units" in lang/en.conf, skin.conf or weewx.conf

[Stefan Gliessmann]

Thx!

I added it in skin.conf, but I still see "undefined" ...

[Stefan Gliessmann]

It is me again ...

As you may remember, I placed a Raspberry Pi and a Ecowitt GW1100 in my RV. (http://rv.stegli.de)

I am able to forward GPS coordinates from by mobile router to WeeWx via MQTT and can display them in the Belchertown skin.

I defined new observations with:

import weewx.units

for group in weewx.units.std_groups:

    weewx.units.std_groups[group].setdefault('group_coordinate','degree_compass')

weewx.units.obs_group_dict.setdefault('latitude','group_coordinate')

weewx.units.obs_group_dict.setdefault('longitude','group_coordinate')

I added new database columns in my weewx db with:

sudo wee_database --add-column=latitude

sudo wee_database --add-column=longitude

I added in weewx.conf that the coordinates are sent under the topic RV and binding to loop & archive

    [[MQTT]]
     server_url = mqtt://xyz:xyz...@teffi71.spdns.de:1883/
     topic = RV
     unit_system = METRIC
     binding = loop, archive
     log_success = true
      [[[inputs]]]

       [[[[latitude]]]]
         name = Latitude
       [[[[longitude]]]]
         name = Longitude

I only noticed today that no coordinates were written to the database. The columns for Latitude and Longitude display "Null".

What do I miss or do not understand? 

I thought that having the topic's binding set to archive would populate the weewx db accordingly ...

This seem not to be the case.

Is this the way it should work?

TIA! :)

[Greg Troxel]

Stefan Gliessmann <stefan.g...@gmail.com> writes:

> I thought that having the topic's binding set to archive would populate the
> weewx db accordingly ...

I think you are missing that MQTT is supported in two distinct ways and
that these two methods have nothing to do with each other.

The mqtt extension
https://github.com/matthewwall/weewx-mqtt
takes data from weewx (archive and loop) and publishes it to
MQTT. This is used to provide data to be read by skins like
Belchertown and things like Home Assistant.

The mqtt-subscribe service/driver
https://github.com/bellrichm/WeeWX-MQTTSubscribe
takes data from MQTT and stores it in the database. This is used to
add sensors to weewx, from data that appears over MQTT.


You should be able to store coordinates with mqtt-subscribe and then
also publish those so HA/skin/whatever can see them. But they are in
the db (or as loop packets) in the middle.

[Stefan Gliessmann]

Thank you, Greg!

That makes so much sense now to me!

🙏😇

[Stefan Gliessmann]

I installed MQTTSubscribe and, as for as I can tell, it is not throwing an error! :) 

However, no coordinates are written into weewx.sdb.

Could this be the reason: user.MQTTSubscribe: (Service) Archive topic is None?

Here a tail -f /var/log/syslog | grep MQTT:

Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) Packet prior to update is: 2023-10-25 15:18:08 CEST (1698239888) 'dateTime': '1698239888', 'inHumidity': '74', 'inTemp': '13.2', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager processing interval: 1698239883.000000 1698239888.000000
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager starting queue RVGPS/# size is: 1
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> outgoing RVGPS/#: 'dateTime': '1698239883.45555', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '1'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager input to accumulate RVGPS/# 2023-10-25 15:18:03 CEST (1698239883): 'dateTime': '1698239883.45555', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '1'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager prior to conversion is RVGPS/# 2023-10-25 15:18:08 CEST (1698239888): 'dateTime': '1698239888.0', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '1'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager after conversion is RVGPS/# 2023-10-25 15:18:08 CEST (1698239888): 'dateTime': '1698239888.0', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '17'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> outgoing accumulated RVGPS/#: 'dateTime': '1698239888.0', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '17'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) Packet after update is: 2023-10-25 15:18:08 CEST (1698239888) 'dateTime': '1698239888.0', 'inHumidity': '74', 'inTemp': '13.2', 'latitude': '52.152477', 'longitude': '9.929382', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) Packet prior to update is: 2023-10-25 15:18:08 CEST (1698239888) 'dateTime': '1698239888.0', 'inHumidity': '74', 'inTemp': '13.2', 'latitude': '52.152477', 'longitude': '9.929382', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) Packet after update is: 2023-10-25 15:18:08 CEST (1698239888) 'dateTime': '1698239888.0', 'inHumidity': '74', 'inTemp': '13.2', 'latitude': '52.152477', 'longitude': '9.929382', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) data-> final packet is 2023-10-25 15:18:08 CEST (1698239888): 'dateTime': '1698239888.0', 'inHumidity': '74', 'inTemp': '13.2', 'latitude': '52.152477', 'longitude': '9.929382', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'
Oct 25 15:18:08 rvwx weewx[32590] INFO weewx.restx: MQTT: Published record 2023-10-25 15:18:08 CEST (1698239888)
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Received PUBLISH (d0, q0, r0, m0), 'RVGPS/loop', ...  (76 bytes)
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) MessageCallbackProvider data-> incoming topic: RVGPS/loop, QOS: 0, retain: 0, payload: b'{"dateTime": "1698239885", "latitude": "52.152477", "longitude": "9.929382"}'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> incoming RVGPS/loop: 'dateTime': '1698239885.0', 'latitude': '52.152477', 'longitude': '9.929382'
Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) TopicManager Added to queue RVGPS/loop RVGPS/# 2023-10-25 15:18:08 CEST (1698239888): 'dateTime': '1698239888.4406571', 'latitude': '52.152477', 'longitude': '9.929382', 'usUnits': '1'

I see also for weewx-mqtt publisher the following.

Here a tail -f /var/log/syslog | grep mqtt:

Oct 25 15:32:21 rvwx weewx[32590] DEBUG user.mqtt: data: {'dateTime': '1698240741.0', 'inTemp_C': '13.299999999999999', 'outTemp_C': '13.000000000000004', 'outHumidity': '86.0', 'pressure_mbar': '986.5', 'relbarometer': '986.5', 'wh31_ch1_batt': '0.0', 'wh31_ch1_sig': '4.0', 'wh31_ch8_sig': '0.0', 'inHumidity': '74.0', 'altimeter_mbar': '990.1050304333165', 'barometer_mbar': '990.0253260380001', 'cloudbase_meter': '315.17323732125936', 'dewpoint_C': '10.711913219964744', 'heatindex_C': '12.601111111111116', 'humidex_C': '14.614171236229963', 'inDewpoint_C': '8.762453683350873', 'rainRate_cm_per_hour': '0.0', 'usUnits': '16.0', 'latitude': '52.152554', 'longitude': '9.929341', 'position': '52.152554,9.929341'}

As for as I understand it, MQTTSubscribe is reading from topic RVGPS the coordinates and adds them to the final package.

Weewx-mqtt publishes under topic RV the updated data; now including latitude, longitude and position (I do not know how "position" was added).

However, latitude and longitude are not updated into weewx.sdb. The values for the columns latitide and longitude (which I added manually) display NULL.

Here is the MQTTSubscribe initialization after a weewx restart.

Here a tail -f /var/log/syslog:

Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) Using weewx version 4.10.2
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) Using Python 3.9.2 (default, Mar 12 2021, 04:06:34) #012[GCC 10.2.1 20210110]
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) Platform Linux-6.1.21-v8+-aarch64-with-glibc2.31
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) Locale is 'en_GB.UTF-8'
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Version is 2.2.2
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Log level: 0
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Log debug setting: 5
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Log console: False
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Log file: None
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) sanitized configuration removed ['password']
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSUBscriber sanitized_service_dict is {'username': 'teffi', 'topics': {'unit_system': 'US', 'use_server_datetime': 'True', 'use_topic_as_fieldname': 'true', 'RVGPS/#': {'ignore': 'False'}}, 'log': 'true', 'port': '1883', 'binding': 'loop', 'enable': 'true', 'keepalive': '60', 'host': 'weewx.bz3gfkrlqtrsc3sv.myfritz.net', 'message_callback': {'type': 'json'}}
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) 'use_topic_as_fieldname' option is no longer needed and can be removed.
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager self.collect_wind_across_loops is True
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager self.collect_observations is False
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager single_queue is False
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager single_queue is False
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager self.subscribed_topics is {"RVGPS/#": {"ignore": false, "subscribe": true, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0xf72d89b8>"}, "unit_system": 1, "msg_id_field": null, "qos": 0, "topic_tail_is_fieldname": false, "use_server_datetime": true, "datetime_format": null, "offset_format": null, "ignore_msg_id_field": [], "fields": {"RVGPS/#": {"name": "RVGPS/#", "ignore": false, "contains_total": false, "total_wrap_around": false, "conversion_func": {"source": "lambda x: to_float(x)", "compiled": "<function <lambda> at 0xf72ed970>"}, "conversion_type": "float", "conversion_error_to_none": false}}, "queue": {"name": "RVGPS/#", "type": "normal", "ignore_start_time": false, "ignore_end_time": false, "adjust_start_time": 0.0, "adjust_end_time": 0.0, "max_size": 2147483647, "data": "deque([])"}, "filters": {}, "message-1698241329.683747": {}}, "1698241329.686176-windGust-windGustDir-windDir-windSpeed": {"subscribe": false, "message-1698241329.683747": {}, "unit_system": 1, "qos": 0, "topic_tail_is_fieldname": false, "use_server_datetime": true, "datetime_format": null, "offset_format": null, "queue": {"name": "1698241329.686176-windGust-windGustDir-windDir-windSpeed", "type": "collector", "ignore_start_time": false, "ignore_end_time": false, "adjust_start_time": 0.0, "adjust_end_time": 0.0, "max_size": 2147483647, "data": "deque([])"}}}
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager self.cached_fields is {}
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) message_callback_provider_name is user.MQTTSubscribe.MessageCallbackProvider
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) clientid is MQTTSubscribe-3055
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) client_session is True
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) host is weewx.bz3gfkrlqtrsc3sv.myfritz.net
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) port is 1883
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) keepalive is 60
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) username is teffi
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) min_delay is 1
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) max_delay is 120
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) password is set
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Archive topic is None
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Sending CONNECT (u1, p1, wr0, wq0, wf0, c1, k60) client_id=b'MQTTSubscribe-3055'
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) binding is loop
Oct 25 15:42:09 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) Starting loop
Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Waiting for MQTT connection.
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Received CONNACK (0, 0)
Oct 25 15:42:10 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Connected with result code 0
Oct 25 15:42:10 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Connected flags {'session present': 0}
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Sending SUBSCRIBE (d0, m1) [(b'RVGPS/#', 0)]
Oct 25 15:42:10 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Subscribing to RVGPS/# has a mid 1 and rc 0
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Received SUBACK
Oct 25 15:42:10 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Subscribed to mid: 1 is size 1 has a QOS of 0
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MQTTSubscribe MQTT: Received PUBLISH (d0, q0, r0, m0), 'RVGPS/loop', ...  (76 bytes)
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) MessageCallbackProvider data-> incoming topic: RVGPS/loop, QOS: 0, retain: 0, payload: b'{"dateTime": "1698241325", "latitude": "52.152546", "longitude": "9.929337"}'
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager data-> incoming RVGPS/loop: 'dateTime': '1698241325.0', 'latitude': '52.152546', 'longitude': '9.929337'
Oct 25 15:42:10 rvwx weewx[460] DEBUG user.MQTTSubscribe: (Service) TopicManager Added to queue RVGPS/loop RVGPS/# 2023-10-25 15:42:10 CEST (1698241330): 'dateTime': '1698241330.3411937', 'latitude': '52.152546', 'longitude': '9.929337', 'usUnits': '1'
Oct 25 15:42:10 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) MQTT initialization complete.

I just notice that there is no archive topic set. Is that the reason why nothing is written to the weewx.sdb?

user.MQTTSubscribe: (Service) Archive topic is None

TIA for any hint!

[bell...@gmail.com]

Oct 25 15:42:09 rvwx weewx[460] INFO user.MQTTSubscribe: (Service) Archive topic is None

This is just saying you are not using an experimental option, archive_topic (https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring-experimental-options#archive_topic).

Oct 25 15:18:08 rvwx weewx[32590] DEBUG user.MQTTSubscribe: (Service) data-> final packet is 2023-10-25 15:18:08 CEST (1698239888): 'dateTime': '1698239888.0', 'inHumidity': '74', 'inTemp': '13.2', 'latitude': '52.152477', 'longitude': '9.929382', 'outHumidity': '86', 'outTemp': '12.9', 'pressure': '987.0', 'relbarometer': '987.0', 'usUnits': '17', 'wh31_ch1_batt': '0', 'wh31_ch1_sig': '4', 'wh31_ch8_batt': 'None', 'wh31_ch8_sig': '0'

This is saying that MQTTSubscribe has updated the loop packet. So WeeWX should be using this to update the archive record and database.

Next steps. Run WeeWX from the command line for a couple of archive periods. This will print the loop packets and archive records to the console. Post the console and complete log, from startup through the archive periods. Double check that the log does not have any sensitive information.

- rich

[Stefan Gliessmann]

Hi Rich et al.,

today, I finally was able to do more trouble shooting ...

I let WeeWX nun from CLI and - surprise, surprise - the archive records included the GPS coordinates.

I double checked in my weewx.sdb and since Oct 25, 2023 14:55:00 the coordinates are recorded in the db!

YEAH :)

I guess I have not looked at the last page of the db before as I have not changed any configuration since Wednesday ... LOL!

Ok - now I just have to figure out why the forecast is not using the coordinates for the Belchertown skin forecast using dwd-mosmix ... once that is achieved, I am extremely happy.

AGAIN - huge thanks to this group whose members always nudges me in the right direction!

Thank you,

Stefan

[Stefan Gliessmann]

I am using the Belchertown skin.

"These settings need to be enabled in order for the skin to work. Within weewx.conf, under [Station] make sure you have:

• latitude - used for forecasting and earthquake data
• longitude - used for forecasting and earthquake data"

How can I change the use of latitude & longitude from the stanze [Station] to current values from the weewx.sdb $latitude and $longitude for weather forecasting?

I want to use the most current poisition for forecasting either thru Belchertown AerisWeather or weewx-DWD dwd-mosix WeatherService with openmeteo.

For both forecasting options, it seems that the location is read from [Station] and not from weewx.sdb $latitude and $longitude.

TIA!

[Karen K]

Stefan Gliessmann schrieb am Samstag, 28. Oktober 2023 um 14:53:30 UTC+2:

How can I change the use of latitude & longitude from the stanze [Station] to current values from the weewx.sdb $latitude and $longitude for weather forecasting? I want to use the most current poisition for forecasting either thru Belchertown AerisWeather or weewx-DWD dwd-mosix WeatherService with openmeteo.

After some discussion there are some ideas on the weewx-DWD wiki page "Wettervorhersage im Wohnmobil".