Database optimations

[John Smith]

I have always been hesitant to mess with the weeWX DB in case I broke it, but I ended up modifying the archive table and made a custom schema to match just in case.

It turned out more fruitful than I expected as I dropped the columns that were only full of NULLs. Worst case I need to re-add them and then the NULLs will be re-added too.

The extended schema has some interesting columns, such as 5 regarding hail, but does anyone know of any hail sensors?

The archive table went from 1.1GB down to 420MB in the process...

The only problem after doing this was weeWX exited on start because I didn't set a default value on the new columns I added, however after setting default values weeWX was happy again.

Then I changed the usUnits and interval columns from Int to tiny int, what that means is instead of MariaDB allocating 4 bytes per value it only uses 1 byte per value. I'm not sure setting those columns as ENUM type would reduce things further, but the usUnits column only has the number 17 stored and the interval column is always set to 5...

It was then I noticed that nearly all the columns were of type double, which seems like over kill to me as most of the time there really is only a need for 1 decimal place, not 16...

So I altered all the double columns and changed them to floats, since doubles use 8 bytes per value verses 4 bytes for floats and this again greatly dropped the table size down to 190MB all up this works out to be almost 1/10th of it's original size.

At this point I think that's the extent that I can take things and thought others might like to know that trimming the archive table, without loosing data, but recover a lot of storage space which will then also speed up other things like backups and reduce the space needed to store backups.

[John Smith]

I spoke too soon, I changed the winddir and windgustdir fields to small ints, saving 2 bytes per value which may not sound like much but it adds up over time...

I also changed the humidity columns to be tiny ints as well...

The above changes saved a further 20MB, and the archive table is just a little over 170MB in size...

[Pablo Sanchez]

That's impressive!

The key is to ensure each data type for all Use Cases captures all data.

On my mental to-do is to enable query tracing to ensure when needed, supporting indexes are available.

---

pablo 

--
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 visit https://groups.google.com/d/msgid/weewx-user/CAGTinV5%3DgG_GkeSucYVX%3DrQSP3%3DL5odJkqvfK%2BFQR3ZCRuVTkQ%40mail.gmail.com.

[John Smith]

I haven't touched indexes, just the number type on the columns..

I went about this by getting unique values for the column and then used that to optimise the column.

The only exception was the winddir column, it had decimal places, but a fraction of a degree doesn't seem worth having.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/19a9283a788.2848.44b74f35a7a433c111dbfaee4cca1c2d%40hillsandlakes.com.

[Pablo Sanchez]

One thought is to to ensure that the data types also cover metric.

---
pablo

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAGTinV6Eq-R9p_5%2BgrMSRxByTXa-O2CQjCUersr-A2Mj9zy3_g%40mail.gmail.com.

[vince]

Pablo, I know you said you're a database guy, but does any of this really matter at all ?

My sqlite3 db is 500 MB in size after a couple weeks short of 19 years.  I can live with that.   It's stable.  It's fast enough.  It works.

[Pablo Sanchez]

Hi Vince,

From John's findings, a single table (the archive table) went from 1.1 GB to 420 MB - 62.7% decrease.

What I do not know is of your 500 MB, how many MBs is your archive table contributing. Let us suppose that it is 1 MB - you are 100% correct. Meh! OTOH, let us suppose it was 480 MB, reduced by 62.7% would be 179 MB. For small form factor devices, that is sizeable:  500 - 480 + 179 = 199 MB. 

For me, I have an old laptop with 8 GB of memory. weewx is now in steady-state (up 15 days since last OS update) and I use very little RAM (692MB). However, I *just* started using WeeWX a few months ago.

I hope that helps!

---
pablo

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/615dea8a-e05f-46e6-84e1-f5e4cd54c377n%40googlegroups.com.

[vince]

Disk is cheap.  The db is not in memory so size of the db does not matter.

Weewx uses a small amount of memory. I used to run it on an ancient ARM box that had 128 MB of RAM.  It ran fine.

The absolute amount of RAM you use depends on os and platform.  On a pi5 mine is around 110 MB RSS and 12 MB shared memory used. If you watch for weeks you might see what looks like memory leaking depending on your os, what actual graphing you are doing, and what underlying python imaging library versions are installed. This is python imaging library at fault under the hood.  Again this doesn't really matter, since the os handles it anyway automatically.

For my sqlite3 db....

archive table is 439 MB in 1,866,971 records

the entire db is 501 MB

for a couple weeks short of 19 years data

We looked at the size of the archive table in detail back in early 2019 (wow) during weewx 4.0 development and concluded it was worth the flexibility to cook up the wview_extended bigger schema rather than to try to try to needlessly optimize for size.   You could delete all kinds of columns that aren't used, but it's not really going to save you anything worth the time to do so, and you'll put yourself at risk of all kinds of side effects if you delete things the various skins expect to be there (example - Belchertown takes 'ages' to run its reports if you are missing a couple columns that it expects)

[Pablo Sanchez]

Hi Vince,

Everything is in memory eh? The only question is how much of it. ;)

The DBMS either performs an in-memory I/O (logical I/O) or a physical I/O followed by a lio.

As for memory leaks, it's doubtful that it is an O/S issue but more than likely a user land leak. Ah, in fact, you mention that it may be related to a Python library (user land).

I'm curious why John's archive table is large compared to yours. Perhaps the MariaDB data types are different than sqlite.

Side note: I mentioned elsewhere, I'm very new to weewx (June of this year). I thought about using Sqlite rather than MariaDB. In the end, I thought that I could (eventually?) contribute by ensuring that the queries had supporting indexes when needed. Not all queries need indexing. I could use the MariaDB tools to possibly fold in changes to Sqlite.

Thx!

---

pablo

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/05d7deb5-0d16-40c4-9b54-b4c861f0af18n%40googlegroups.com.

[Mark Fraser]

On 17/11/2025 14:05, John Smith wrote:
> I have always been hesitant to mess with the weeWX DB in case I broke
> it, but I ended up modifying the archive table and made a custom
> schema to match just in case.
>
> It turned out more fruitful than I expected as I dropped the columns
> that were only full of NULLs. Worst case I need to re-add them and
> then the NULLs will be re-added too.
>
> The extended schema has some interesting columns, such as 5 regarding
> hail, but does anyone know of any hail sensors?

I didn't until I searched for them:

https://www.siapmicros.com/en/sistemi-di-misura/hail-precipitation/

https://www.isaw-products.com/hailflow-hf4/

https://elscolab.com/en-nl/products/acoustic-hail-sensor

And the most impressive:

https://www.kisters.eu/product/hail-risk-mitigation/

Seeing as none of them provide a price, I doubt they'll be for the hobbyist.

[Tom Keffer]

Until V4.0 (released 30-Apr-2020), the default database was what we call the "wview" database, with 49 observation types. After that, the default became the "wview_extended" database with 122 entries. That's over twice the size.

Some of the disk space is taken up by the indices, so it's not a straight linear relationship between entries and database size.

If you're really concerned about disk space, it certainly makes sense to drop unused columns. 

-tk

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/19a9332bfc0.2848.44b74f35a7a433c111dbfaee4cca1c2d%40hillsandlakes.com.

[Pablo Sanchez]

Hey Tom,

Some of the disk space is taken up by the indices, so it's not a straight linear relationship between entries and database size.

IIRC, aside from the DB journal, SQLite stashes all the information in the file: table + indexes.

If you're really concerned about disk space, it certainly makes sense to drop unused columns. 

I think you mean that for someone else. :).

Cheers!

---
pablo

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEDRd-wT%2B56uik8cCp6q0%2BZKsZEgcf7yPc8SbcB0%2BabVMQ%40mail.gmail.com.

[John Smith]

On Tue, 18 Nov 2025 at 05:19, vince <vince...@gmail.com> wrote:

Disk is cheap.  The db is not in memory so size of the db does not matter.

What program doesn't use memory to perform actions on data? That statement makes no sense.

Further to that MariaDB can cache lots of data in spare memory to speed things up.

 

Weewx uses a small amount of memory. I used to run it on an ancient ARM box that had 128 MB of RAM.  It ran fine.

Where did I mention weeWX? All my comments relate to MariaDB.

 

For my sqlite3 db....

archive table is 439 MB in 1,866,971 records

the entire db is 501 MB

for a couple weeks short of 19 years data

I have data back almost that far as well, but now my DB is a fraction the size it used to be without any downside than a little DB tuning...

 

concluded it was worth the flexibility to cook up the wview_extended bigger schema rather than to try to try to 

I also covered this point, that removing unused columns and needing them later I would end up with all the NULLs they previously had, but if I don't use them I don't waste resources on them.

[John Smith]

On Tue, 18 Nov 2025 at 04:06, Pablo Sanchez <pa...@hillsandlakes.com> wrote:

One thought is to to ensure that the data types also cover metric.

I store data as metricwx...

In any case the tuning steps would be the same for imperial, check columns for unique values, and set columns number types accordingly... 

However the biggest saving was changing the columns from double to float, this would nearly halve things because you go from 8 bytes per value down to 4 bytes, there is no need for using double because that allows for 16 decimal places of precision and a much bigger numbers as well which is well beyond what's needed when only 1 decimal place is usually required.

[John Smith]

concluded it was worth the flexibility to cook up the wview_extended bigger schema rather than to try to try to 

How is having 5 columns for hail being flexible, so far no one so far has replied to my question if such sensors even exist... 

[vince]

For heaven's sake man, are you off your meds or something ?

Lighten up.  If you don't like it, don't run it.

Sheesh.

[John Smith]

Which is why I dropped those columns, and in turn you turn around an bemoan people doing DB tuning...

I can't see how it would be about flexibility, like you claimed, as it'd be more of a thought bubble best I can tell...

So yes I was very surprised that there would be so many columns, I ended up dropping over 80 I think, just to be filled with NULLs when you claimed to have put thought into the issue in 2019...

--

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 visit https://groups.google.com/d/msgid/weewx-user/8b342aad-f9d9-4b49-92ed-949d61c6db34n%40googlegroups.com.

[Cameron D]

Yes,

right from the start I used a custom schema, derived from wview, with floats rather than doubles. I figured that was more useful as I run a 1 minute interval.

I also trimmed out most of the unused columns. This did cause extra problems when version 5 came along as the default skin started recalculating some of the derived quantities and chewing up lots of cpu cycles.

That gave me the choice of either adding the columns back in or tinkering with the skin.

So I am happy with the result and have to remember not to complain when I get to reassemble the broken bits.

And I know nothing about hail - except that the recent storm with 5cm hail  took chunks out of the top of my rain collector and off the bottom of the Stephenson box.  And one cup of the anemometer is missing (but I don't know it that was hail or cockatoos)

[John Smith]

On Tue, 18 Nov 2025 at 18:21, 'Cameron D' via weewx-user <weewx...@googlegroups.com> wrote:

Yes,

right from the start I used a custom schema, derived from wview, with floats rather than doubles. I figured that was more useful as I run a 1 minute interval.

How big is your DB? MQTT sending loop packet info not an option?

 

I also trimmed out most of the unused columns. This did cause extra problems when version 5 came along as the default skin started recalculating some of the derived quantities and chewing up lots of cpu cycles.

I only removed columns that only had NULLs, which I figured can't have been useful or used at all...

 

So I am happy with the result and have to remember not to complain when I get to reassemble the broken bits.

That's what stopped me previously, but I wanted to add forecast columns the Vantage console already sends, but wasn't being saved, after adding them the data just started flowing immediately...

 

And I know nothing about hail - except that the recent storm with 5cm hail  took chunks out of the top of my rain collector and off the bottom of the Stephenson box.  And one cup of the anemometer is missing (but I don't know it that was hail or cockatoos)

Sorry to hear about your loss...

A previous station from the early 2000s lost an anemometer arm, that I can only put down to UV, there wasn't any hail at the time.. Maybe a fat pigeon sat on it and broke it off... I still haven't taken the broken wind sensor down and it still has the other 2 arms almost a decade later... So who knows what the actual cause was...

I have since been sent a link to a listing that claims to be an all in one sensor that can record hail, but it also says suitable for the highway what ever that means... and +/- 10% accurate...

https://www.alibaba.com/product-detail/RS485-RS232-SDI12-ABS-MODBUS-RADAR_1601167771067.html?

[Cameron D]

Turns out that today was the 9th anniversary of my weewx DB.  PhpMyAdmin told me that my Db consumes 206MB in total - but it also said there were ~1.7M records.

After panicing slightly, I found  that a count() query said there were a more reasonable 4.7M rows and the directory with the DB is using a bit over 500MB.

There is no MQTT, but I don't understand how that could have any effect on storage.

[John Smith]

On Tue, 18 Nov 2025 at 23:43, 'Cameron D' via weewx-user <weewx...@googlegroups.com> wrote:

There is no MQTT, but I don't understand how that could have any effect on storage.

I'm curious why you need such a small update interval as I don't notice many changes in 5 minutes most of the time, and I think I saw that weeWX keeps track of min/max from loop packets for the archive period...

Some skins use MQTT to display information from loop packets that fire every few seconds and then show it on web sites. In this situation it's to keep the information as fresh as possible, without needing to store it in small update intervals. Everything else would still come from the archive packets.

[Cameron D]

It's all just idle curiosity and most of the time nothing changes in 5 minutes, but when a storm cell come through things change very quickly. That last one, for example, had a rain event that was over in 9 minutes (although the hail followed). The heaviest rain was 6mm in one minute, with 23mm over the 9 minutes.  The wind peak  occurred 2 minutes before the rain peak.

I got interested in looking at the detail when Weather Underground tagged my system as "unreliable" (or it lost its gold star or something - I forget the details) due to  a sudden temperature drop of over 5deg C.

I started thinking the wind must have been blowing the rain through the Stephenson box and cooling the sensor, but then noticed that sometimes the temperature drop occurred before the rain - so I am guessing that is more liekly downdrafts from the storm cell.

[John Smith]

On Wed, 19 Nov 2025 at 01:49, 'Cameron D' via weewx-user <weewx...@googlegroups.com> wrote:

It's all just idle curiosity and most of the time nothing changes in 5 minutes, but when a storm cell come through things change very quickly. That last one, for example, had a rain event that was over in 9 minutes (although the hail followed). The heaviest rain was 6mm in one minute, with 23mm over the 9 minutes.  The wind peak  occurred 2 minutes before the rain peak.

That's exactly the use case for MQTT and data from loop packets, and it's even more frequent than minutely, but it doesn't need to store loads of data when nothing is happening :D 

[Cameron D]

" That's exactly the use case for MQTT and data from loop packets..."
No, it is a different  use. I am interested in retaining historical records. When the storm was on I had no time to look at transient records, and afterwards I was inspecting damage and working out what needed immediate attention.

The 1 minute interval is a trade-off I accepted for storing the occasional rapidly changing conditions against extra storage volume.  The other example I quoted, it was months afterwards when I looked at the detail.

[michael.k...@gmx.at]

If I wanted to have a 1-minute-interval for occasional looking into data I'd set up an extra WeeWX instance for it that only stores db values, without an active skin, beside a standard installation with a 5-minute-interval.

[John Smith]

On Wed, 19 Nov 2025 at 15:32, 'Cameron D' via weewx-user <weewx...@googlegroups.com> wrote:

The 1 minute interval is a trade-off I accepted for storing the occasional rapidly changing conditions against extra storage volume.  The other example I quoted, it was months afterwards when I looked at the detail.

If it were me I'd try and figure out when extra data actually changed enough to need storing rather than using a sledge hammer to swat a fly...

[John Smith]

On Wed, 19 Nov 2025 at 18:01, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

If I wanted to have a 1-minute-interval for occasional looking into data I'd set up an extra WeeWX instance for it that only stores db values, without an active skin, beside a standard installation with a 5-minute-interval.

How would that work?

I thought there could only be 1 connection to a console at a time?

[michael.k...@gmx.at]

Depending on the hardware used, there might be some limitations that apply. With my setup, I query multiple consoles from a single Instance, also specific consoles are queried from multiple instances running on different hardware devices.

To be more specific:

- 5 consoles, 2x GW200, 2x GW3000, 1x ws28xx

- Four WeeWX instances on a n100 Platform (ecowitt gateway driver, ws28xx driver)

-- 1 Instance querying the two GW2000

-- 1 Instance for GW2000#1

-- 1 Instance for GW2000#2

-- 1 Instance for ws28xx

- Three WeeWX instances in a containerized ubuntu on a QNAP NAS (ecowitt_http driver)

-- 1 Instance querying the two GW3000

-- 1 Instance for GW3000#1

-- 1 Instance for GW3000#2

For each instance I could choose whatever interval I'd be happy with. Having Terabytes of storage on this devices, that would be running 24/7 anyway, I'd definitely go for this most straight forward approach, if I had the desire to persist my observations in an 1-minute-interval. I wouldn't use an 1-minute-interval with a skin(because the chart look kind of ugly for some obs_types), especially not a skin with JS-generated charts, because having five times the data points massively impacts the rendering performance in the front end.

[John Smith]

On Wed, 19 Nov 2025 at 19:48, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

Depending on the hardware used, there might be some limitations that apply. With my setup, I query multiple 

I'm pretty sure I read an email on this list the other week that they were having problems with weeWX attempting to access a console while the console itself was trying to also do uploads to WUnderground at the same time, I guess it will depend if Cameron has a similar console to what you're using...

I've had a little more time to think about Cameron's needs and wants and I'd be more inclined to just use a single weeWX instance and log all loop packets to a database and then scan past records afterwards that have little or no changes between them and delete them.

That way when something actually happens you have, depending on console and sensors and all that, 10s of data readings per minute, rather than 1... Just delete the uninteresting stuff...

 

For each instance I could choose whatever interval I'd be happy with. Having Terabytes of storage on this devices,

I'm using a 1TB USB SSD with my SBC running weeWX, but it only has 4GB of RAM and it's a slow-ish arm CPU, so storage isn't the limiting factor, the CPU would be the bigger issue out of the 3, so getting as many as possible columns to have smaller number types (ie less bytes per value) should make an improvement, not just on day to day use by weeWX, but on other important things like daily backups of data...

 

that would be running 24/7 anyway, I'd definitely go for this most straight forward approach, if I had the desire to persist my observations in an 1-minute-interval. I wouldn't use an 1-minute-interval with a skin(because the chart

People using the Belchertown skin, maybe others too but I'm not aware of them, use MQTT for sub-minute updates of their websites from loop packets, but they don't try and store all that data for future use...

[michael.k...@gmx.at]

There are a couple of skins with live weather feed, see https://github.com/weewx/weewx/wiki#skins for a (probably incomplete) list. Anyway, I'm not committed in persisting anything in another interval than the default. What I do emphasize is min/max values and their closest-to-exact time of occurrence to be recorded correctly. But that available out-of-the-box, on database level (to get at least a little bit back to topic)

[John Smith]

On Wed, 19 Nov 2025 at 21:09, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

 emphasize is min/max values and their closest-to-exact time of occurrence to be recorded correctly. But that 

I don't have details but I somehow got the impression that weeWX used max/min in loop packets as part of archive records... I could be wrong...

That sort of thing isn't that interesting to me as little usually changes in 5 minutes and the pressure reading only updates every 15 minutes or something, so it's with all the other useless tidbits rattling round in the back of my brain...

[Cameron D]

The WUnderground stuff was purely via weewx, and I have never bothered with the rapidfire side.  My console is a WMR300, which has no direct WUnderground access, and in fact no network at all (USB only).  This also is the reason why initially the mysql and weewx hosts were separate.  The mysql server that was already doing other things did not have usb access.

I have never bothered to implement anything fancier, because it seems that, being retired, I have no spare time.  (perhaps it is really that, being old, everything takes so much longer).

The kiss principle says that by the trivial process of  increasing the number of rows by a factor of 5, while reducing number of columns by a factor of 3 and halving the number of bytes per column means that I have achieved a "good enough" situation without any significant effort. Allowing for a larger index means my system  is probably close to the default size anyway.

I did try Belchertown, perhaps 8 years ago, without much success, so perhaps the short interval was what upset it.

[michael.k...@gmx.at]

Your impression is wrong, these values are stored in the archive_day_* tables. But: they can be dropped and rebuilt from archive, if you do that, you lose the original values, resulting in probably changing the one or the other alltime record.

[Graham Eddy]

see weewx “Accumulators” on how the loop values are rolled up into the archive values (default for new obstype is ‘avg’)

⊣GE⊢

[John Smith]

On Wed, 19 Nov 2025 at 21:40, 'Cameron D' via weewx-user <weewx...@googlegroups.com> wrote:

The WUnderground stuff was purely via weewx, and I have never bothered with the rapidfire side.  My console is a

No it was someone else and their console must have been IP based... My point was their console, and USB ones especially for that matter, don't usually cope with multiple connections, if at all to be able to have a setup with 2 instances of weeWX with 2 different archive reporting periods...

 

The kiss principle says that by the trivial process of  increasing the number of rows by a factor of 5, while reducing number of columns by a factor of 3 and halving the number of bytes per column means that I have achieved a

It probably isn't linear like that, so the losses would probably still outweigh any gains...

 

"good enough" situation without any significant effort. Allowing for a larger index means my system  is probably close to the default size anyway.

That was also my point, I had 80+ columns just storing NULLs, compared to just over 30 columns with data, now my DB is just over 1/10th it's former self with no data loss... and if the arm processor coped with a 1.1GB table it should do even better now that the table is just over 170MB...

 

I did try Belchertown, perhaps 8 years ago, without much success, so perhaps the short interval was what upset it.

I haven't tried it, nor MQTT for that matter, but I am still marginally aware of the underlying principals...

[John Smith]

On Wed, 19 Nov 2025 at 21:56, Graham Eddy <g...@geddy.au> wrote:

see weewx “Accumulators” on how the loop values are rolled up into the archive values (default for new obstype is ‘avg’)

Not that I'll ever try it, but I remembered correctly that weeWX is capable of such things, you just need to configure it to do so?

[Graham Eddy]

weewx.conf [Accumulators] stanza

⊣GE⊢

--
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 visit https://groups.google.com/d/msgid/weewx-user/CAGTinV7z_yDTpbAcWpo0g9F5_fpXKcGA3vv0cjTYoHKruoP5EQ%40mail.gmail.com.

[John Smith]

On Wed, 19 Nov 2025 at 23:07, Graham Eddy <g...@geddy.au> wrote:

weewx.conf [Accumulators] stanza

A simple yes or no would have sufficed, as I'm not actually looking for help to implement anything.

Searching the web for the above terms returns very little that seems relevant to my question by both duck duck go and google...

Most search engines got gamed long ago for various reasons and then AI came along and compounded the problem...

[John Smith]

Google's AI bot says no....

[michael.k...@gmx.at]

Good old human intelligence combined with querying a web search engine, which you just mentioned above, finds the following: https://github.com/weewx/weewx/wiki/Accumulators. This should answer many questions that might have arisen if the previous questions had been answered with a simple “yes.”

[John Smith]

On Wed, 19 Nov 2025 at 23:39, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

Good old human intelligence combined with querying a web search engine, which you just mentioned above, finds

I didn't invest a lot of time in researching about something I have no interest in... I was given some search terms, but the search engines didn't come back with anything useful to them, in any case I was only curious but have no plans to move it beyond the thought bubble stage...

 

the following: https://github.com/weewx/weewx/wiki/Accumulators. This should answer many questions that might have arisen if the previous questions had been answered with a simple “yes.”

Couldn't you have been any more passive aggressive and condescending?

[michael.k...@gmx.at]

I tried, but it would have meant switching to active aggressiveness, which, obviously, is the part you have mastered. In fear of not being capable of keeping up, I decided I'll stay at a level of aggressiveness I'm comfortable with.

[John Smith]

On Thu, 20 Nov 2025 at 00:22, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

I tried, but it would have meant switching to active aggressiveness, which, obviously, is the part you have 

Which was entirely out of frustration after reporting a serious issues through official channels only to be told that a slight change to documentation was all that would be done about it, what would you have done differently?