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/f53dcab0-d6c9-45d2-a824-fd23eba26e27n%40googlegroups.com.
