You need to figure out your requirements.
- there are over 100 possible elements in a default weewx schema
- which measurements do you want to display and compare among your
stations ?
If you're just looking for the most typically used items (outTemp, wind,
windGust, windDir, rain) then MQTT would be very very easy to set up.
> "I* haven't dealt with MQTT, but [...] I hope this protocol has the
ability to announce/send to a remote server."*
That is EXACTLY how it works. The client(s) publish information to the
server. The server subscribes to whatever information it is configured to
care about.
1. On your weewx client system, use Matthew's weewx-mqtt extension to
publish weewx data to the MQTT server (aka 'mosquitto broker'):
[[MQTT]]
enable = true
client_id = mysite1 # optional
server_url = mqtt://192.168.1.69:1883/ # or the FQDN of the
broker computer
append_units_label = false # default=True
binding = loop,archive # or archive or loop
alone
topic = mysite1 # use a different topic
per client computer
log_success = false
log_failure = true
(you can use Rich's MQTTpublish extension if you want - syntax is a little
different but similar)
2. On the target server use Rich's MQTTsubscribe to subscribe to the items
you want, from the clients you want, and save them to the weewx db to some
column in your schema.
This example runs it as a service to add incoming data from MQTT to the
normal data from my VP2 station, but it can run as a MQTTSubscribeDriver if
you want. If you run it as a driver on your central weewx server it will
just save data coming in from whatever client systems you configure to
publish to it. You'll likely need some custom set of columns in your
central weewx instance db but that's easy to add.
[MQTTSubscribeService]
enable = true
host = 192.168.1.69 # or the FQDN of the broker computer
port = 1883
keepalive = 60
username = None
password = None
binding = loop
[[message_callback]]
type = json
[[topics]]
unit_system = US
ignore_start_time = True
ignore_end_time = True
[[[mysite1/loop]]] # subscribe to data published by the
mysite1 weewx instance
[[[[outTemp_F]]]] # extract its outTemp item
name = extraTemp1 # save to the local db using
extraTemp1
units = degree_F
[[[mysite2/loop]]] # similarly for mysite2
[[[[outTemp_F]]]]
name = extraTemp2
units = degree_F
3. And of course set up whatever custom skin with tabular data and/or
graphs that you want for visualizing.
==> Experiment a little with MQTT while you think about your requirements.
If you want to learn MQTT this is very well documented online, but if you
look at the Belchertown-from-scratch repo I mentioned this week there is a
page that should walk you step-by-step. See
https://github.com/vinceskahan/belchertown-from-scratch/blob/main/configure-websockets-no-encryption.md
and ignore the Belchertown mentions therein. The rest shows how to install
and test mosquitto MQTT enough to get a feel for it.
On Sunday, February 22, 2026 at 1:24:27 AM UTC-8 Tomasz Lewicki wrote:
> First of all, thank you for the wide response and the whole list of ideas.
> For now, I am at the stage of developing a concept for how to build such a
> network and manage it, at least in terms of configuration files. I assume
> that all stations will have access to high-speed internet (this will be one
> of the installation requirements, apart from the terrain conditions), so
> the amount of data transferred from the stations to the central server - if
> I need one - will not be a bottleneck.
>
> I haven't dealt with MQTT, but since you say it's not difficult, all the
> better. I hope this protocol has the ability to announce/send to a remote
> server.
>
> I have come up with another solution, although I am not sure if it
> duplicates any of the proposed ones - as I mentioned, I have not delved
> into the subject yet. If I am reinventing the wheel, please let me know. At
> the stage of starting each station, I would add additional columns to the
> individual weewx.sdb database, which would be copies of other columns,
> e.g., archive_day_outTemp_stationID (where stationID is, of course, a
> unique key - the name of the station). Before sending the database to the
> server, a script would cut out only the *_stationID columns, save them to a
> new database, and send this truncated database to the central server.
> However, I see a problem here in the form of additional CPU overhead and,
> perhaps most importantly, an increased number of records on the microSD
> card (as I wrote in my first post, I want to have Weewx on Raspberry Pi).
> So transferring the entire database, even with additional columns, and
> processing it in one place may be a better solution.
>
> As for summaries, at first I didn't consider data visualization, only
> simple tabular summaries, e.g., maximum temperature in the entire area -
> station X, minimum temperature - station Y, etc. But I'm sure that over
> time, you'll want to have graphs and images :)
>
> niedziela, 22 lutego 2026 o 01:42:09 UTC+1 [email protected] napisał(a):
>
>> Here is my understanding of the problem.
>>
>>
>> There are multiple databases on different physical machines and it is
>> desired to create data visualizations that combine them.
>>
>>
>> Cat skin 1.
>>
>> A central visualization process that can access the remote data sources.
>>
>>
>> Cat skin 2.
>>
>> Replicate the databases “asis” to a central location and run the
>> visualization off these replicas.
>>
>>
>> Cat skin 3.
>>
>> Replicate the data of interest into a central database and run the
>> visualization off this central database
>>
>>
>> Cat skin n.
>>
>> I am sure there are many more options.
>>
>>
>> My gut, the first decision is whether to try to access the remote data
>> sources from a central location (cat skin 1) or replicate the required
>> data to the central location (cat skin 2 and 3). Then proceed from there.
>>
>>
>> Then layered on top of (or underneath, since we have skinned the cat?),
>> the various technology that can be used.....
>>
>> On Saturday, 21 February 2026 at 19:00:24 UTC-5 Graham Eddy wrote:
>>
>>> the question, as i understood it, was to present from single copy of
>>> data already existing, rather than to store multiple copies of the same
>>> data in multiple databases.
>>> i use mqtt extensively for data acquisition, creating single truths in
>>> databases. then i have a presentation layer over the top of all to create a
>>> single (complex) portal (which has more than just weewx data).
>>> as vince and others point out, there is more than one way to ’skin a
>>> cat’ and it depends on your requirements
>>> *⊣GE⊢*
>>>
>>> On 22 Feb 2026, at 5:30 am, Vince Skahan <[email protected]> wrote:
>>>
>>> For just a few readings from just a few stations, MQTT is the simplest
>>> way:
>>>
>>>
>>>
>>>
>>>
--
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/95f43685-471f-4910-9318-3acb7ba82b48n%40googlegroups.com.
