complete editability of weewx.conf

[Vince Skahan]

Would some kind of utility to permit simple edits of 'any' item in weewx.conf be of any value to think about ?

Something like "weectl edit config" or the like (for discussion purposes) ?

# edit weewx.conf

weectl edit config --set "[StdRestful][[MQTT]]" --key "log_success" --value "true"

or

# edit a skin's skin.conf

weectl edit skinConfig --skin "Belchertown" --set "[Extras]" --key "belchertown_debug" --value "1"

I know simply telling them 'edit the file dude' of course works, but it might be helpful for scriptability if there was a way to automate add/edit/comment/uncomment things programmatically.  The use of configobj makes this really hard to do without some wrapper utility being cooked up.

I did think about some alternate ways:

• convert the .conf in configobj format to JSON or YAML
• edit thataway
• convert it back to configobj format

But that would be ugly at best and likely would lose any comments from the .conf file.

No short-term need, but thought I'd ask if it might be a longterm stretch goal (?)

[Peter Fletcher]

Other than enhancing scriptability - largely, I would imagine for initial installations - I am not sure that I see the value of this, particularly given the very substantial amount of work involved in implementing it. I think that it is easier for the user who isn't a unix guru to go through the well documented .conf file and identify and make the changes that (s)he needs. For those who are unix gurus, and are used to (and possible even like!) its complex command line syntax, it might be faster to make a single change this way, but you frequently aren't just making a single change.

Just my 2 cents!

[Greg Troxel]

Vince Skahan <vince...@gmail.com> writes:

> Would some kind of utility to permit simple edits of 'any' item in
> weewx.conf be of any value to think about ?
>
> Something like "weectl edit config" or the like (for discussion purposes) ?
>
> # edit weewx.conf
> weectl edit config --set "[StdRestful][[MQTT]]" --key "log_success" --value
> "true"

Perhaps, but this is something that really should be implemented in
configobj first -- is that already there?

Can configobj read a file into some pythonic data structure, let you
change it, and then write it, and have that result in no changes (or
formatting regularization that is stable), in particular preserving
comments? Is the implementation just parsing the headings and
assigning a variable, after read and before write?

(I presonally would prefer
--set /StdRestful/MQTT/log_success=true
but I realize that's turning windows ini back into unix paths and
everybody else wouldn't like that!)

> I know simply telling them 'edit the file dude' of course works, but it
> might be helpful for scriptability if there was a way to automate
> add/edit/comment/uncomment things programmatically. The use of configobj
> makes this really hard to do without some wrapper utility being cooked up.
>
> I did think about some alternate ways:
>

> - convert the .conf in configobj format to JSON or YAML
> - edit thataway
> - convert it back to configobj format

>
> But that would be ugly at best and likely would lose any comments from the
> .conf file.

configobj talks about round trip:

ConfigObj is a simple but powerful config file reader and writer: an
ini file round tripper. Its main feature is that it is very easy to
use, with a straightforward programmer’s interface and a simple syntax
for config files.

* All comments in the file are preserved

* The order of keys/sections is preserved

so in theory this should work.

It should be easy enough to test with

read weewx.conf to python data structure
write that to weewx.conf.roundtrip

and diff.



I remember problems with earlier config updates (maybe 4 years ago)
where the generated config would have some odd whitespace that was
different from the standard config file. But I think that's no longer
the case.

[Vince Skahan]

Not a big deal - I was mainly asking to see if more than a few sometimes thought this was an itch worth scratching.

In my case I was trying to script ala-carte bill-of-materials based builds using ansible.  The basic problem that weewx lets a third party developer put anything they want into any location within the namespace.  So there might be multiple 'debug = 0' or 'log_success = true/false' items in weewx.conf and it is not possible using ansible nor puppet nor any other tool I've found to let you automate setting 'just THAT one' to a desired value.

Maybe there isn't a good solution for something so extensible.   I was just asking if others have thoughts....

[Vince Skahan]

One more wild set of questions.....

In the other thread Tom mentioned that nowadays he'd look at TOML format since it's no longer 2008.

If we had a clean sheet of paper today what would it look like ?

Would it look more like a modern unix system's setup ?

• perhaps use TOML format as Tom mentioned or JSON or YAML - doesn't really matter perhaps
• but don't simply redo a monolithic weewx.conf into a different format
• instead also think ala-carte componetization.  Add/delete 'files' to a conf.d directory like modern apps do

Think about how the mosquitto broker is configured.  One toplevel mosquitto.conf file that reads a conf.d directory containing 'components' it adds up as it starts.  Similarly how nginx has the concept of 'sites-enabled' where you can pick which of the 'sites-available' you want to start. 

So just wildly thinking about a what-if for discussion purposes - using nginx's way as an example:

Toplevel config with defaults (?)

• /etc/weewx/weewx.conf

All ala-carte added and selectable items:

• /etc/weewx/conf.d/components-available/mything.conf

Out of that list, the set of what is enabled:

• /etc/weewx/conf.d/components-enabled/mything.conf - symlink to 'components-available' file or a copy of it ala nginx

So run this to see today's tree structure:

• grep "\[" weewx.conf

What do you see ?

• add-ons can add to lines within a [[ ]] block
• add-ons can add to lines within a [ ] block
• add-ons can add things to things currently at the toplevel above any [ ] nesting
• anything goes basically - that's not necessarily good or bad of course...

Just thinking about a few examples that make different modifications to weewx.conf currently....

weewx-mqtt:

• adds a [StdRESTful] [[MQTT]] block
• adds to the list of restful_services in [Engine] [[Services]]

or MQTTSubscribe:

• adds to the list of data_services in [Engine] [[Services]]
• adds a 'toplevel' [MQTTSubscribeService] block

or Belchertown skin:

• adds a [[Belchertown]] block to [StdReport]
• but adds its services into its skin.conf

of the GW1000 driver:

• adds a toplevel [GW1000] driver block like every other driver does
• adds a zillion items under [Accumulator]

So given add-ons can (and do) add to items at basically any level in the namespace, is that good long term ?

If we go with TOML for discussion purposes, configuring weewx-mqtt would look like:

[StdRESTful.MQTT]

        enable = true
        client_id = vp2
        server_url = mqtt://192.168.1.69:1883/
        append_units_label = false
        topic = vp2
        log_success = false
        log_failure = true

[Engine.Services]

       restful_services = user.mqtt.MQTT

Hopefully this 'adds' to the list of assembled restful_services that run at a system level.

I don't know.  Does TOML help today's as-is ?  Does componetizing ?  I really don't know.

Ultimately the user has to edit 'something' eventually I guess...

[Joel Bion]

Random thoughts 

If this is for an extension you are building, you could always name your parameters with a common (and extremely unlikely to be used by others) prefix.

If instead you just want to change just the variables located in some particular section(s), then you’d have to build a little parser that keeps track of the current headings nesting, and only changes the entries in the configuration sections that matter to you.

On Feb 26, 2026, at 11:26 AM, Vince Skahan <vince...@gmail.com> wrote:

One more wild set of questions.....

--
You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-development/9a950eaf-766c-47d5-8f29-4d17bb8e15can%40googlegroups.com.

[Peter Fletcher]

I think that there are many weewx users who, like me, would strongly deprecate anything that resulted in a major restructuring of weewx.conf into multiple files. Right now, you know where everything is, so on the (relatively rare, for me) occasions when you need to change something, you can do a text search of weewx.conf to find it, or, if all else fails, page through it to find the relevant section. I run a number of utilities that have multiple config files, and, when I want to make a configuration change, I can never remember which file controls that functionality. I think that this is something in weewx that 'aint broke'!

[Vince Skahan]

Absolutely.  Definitely don't want to break anything or anybody.

I did take a pass at converting my relatively big weewx.conf to TOML and doing a little light editing to illustrate what a fully configured system might look like.  It's actually the same number of lines as weewx.conf believe it or not.  I cut/paste things to get them together for illustrative purposes.

But this is what hypothetically a weewx.conf converted to TOML would look like.  I run a lot of skins and a few extensions.

[Tom Keffer]

wview structured its configuration into multiple files. I was never very keen on the idea. You never knew where to look, and there was a constant treasure hunt with Michael trying to find the key option. Later, he started adding configuration information to a sqlite database, and that made things even worse.

When I started on WeeWX, one of the first decisions I made was that everything would go into one file, no matter how big. This way, all the state is in one place; everything you need to know about a user's configuration is in that file. For the same reason, there are no environment variables and no command line options.

Yes, the file is large, but it is well-structured. I think it has stood the test of time.

-tk

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 26 Feb 2026 13:12:58 -0800 (PST)
Vince Skahan <vince...@gmail.com> wrote:

> I did take a pass at converting my relatively big weewx.conf to TOML
> and doing a little light editing to illustrate what a fully
> configured system might look like. It's actually the same number of
> lines as weewx.conf believe it or not.

¡We don' need no steenkin' comments! :-) ¡Or indentation!

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx
.. 39° — Wind SW at 15 mph. Sky clear.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaaDDXwAKCRBg2/xipKOW
Utt9AJsEiJXpSiCG36R64f735dRAaMERBwCdHPKILGHswBR6r1ILVukV+Awb6dQ=
=kG4L
-----END PGP SIGNATURE-----

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 26 Feb 2026 11:26:49 -0800 (PST)
Vince Skahan <vince...@gmail.com> wrote:

> ... one toplevel mosquitto.conf file that reads a conf.d directory

> containing 'components' it adds up as it starts. Similarly how
> nginx has the concept of 'sites-enabled' where you can pick which of
> the 'sites-available' you want to start.

Iyam amused that anyone would wish to emulate *nginx's* config
technique.

Iyam not sure exactly what problem(s) y'all are trying to solve.

Is it (b) — automagically identifying which parts of the *weewx*
config belong to which extensions? Then the *conf.d* approach is
superior. It isolates all the parameters that a given extension needs
in one element (Sperry/Univac/Unisys OS/1100 terminology). To
uninstall, you have merely to get ahold of the correct element and
delete it. The swindle is that (I think.) you have to specify where in
the root config the inclusions are automatically applied. Certainly
you have to specify any inclusions from elements outside the *conf.d*
structure.

The problem with *conf.d* is that extensions may wish to "share"
parameters with the top-level *weewx* config (and with each other).
If an extension specifies a parameter setting at odds with the
prevailing settings, then the last extension installed (loaded) wins.
This is a source and even an invitation to error. Such errors would be
extremely difficult to diagnose because you'd manually have to examine
all *conf.d* elements in the sequence of their inclusion. OR
... you'd have to agree to protect some set of sacrosanct top-level
settings from being overridden by second (and third) level *conf.d*
elements. Of course, second-level *conf.d* elements might then want to
protect THEIR settings, too. Yechhh!

There would be list-valued settings like
[Engine][[Services]]xtype_services that *conf.d* elements could append
to rather than override, too, sort of like the *bash* environment with
precedence but no priority.

Or are you trying to solve (a) — automagically installing an extension
without prior knowledge of the pre-existing *weewx* config (and other
already installed extensions) — and hoping not to introduce any
conflicts? It seems to me that the possibility of conflicts begs the
question of prior knowledge. Perhaps, like *nginx*, you could audit
the *weewx* config (and all included environments in order of
precedence) on every execution before loading it and just choke to
death on any fatal incompatibilities found. Of course you could
always kvetch to the system log about any less-than-fatal
incompatibilities and deprecated settings.

I, myself, would like to see a *qt* graphical front-end to *configobj*
if not *weewx.conf*. There ought to be a schema for a given
*configobj* application such as *weewx* that shows which parameters are
required/optional and valid values for them (like there are schemas
for various XML applications by which instances may be verified).
Then such a GUI would be cake. But the reality is, "The cake is a
lie," not because *configobj* has no schema validation (It does!), but
because a schema has not been written for *weewx* — at least not to my
knowledge.

Anyway, nothing stops me from writing a *qt* editor for *weewx.conf* I
guess. I couldn't verify or even identify very well the parts that
belong to extensions, but I could highlight a lot of misspellings,
poor punctuation, and bad nesting that are commonly the cause of
complaints here. I don't need *json*. I can certainly create a
*python* structure from *configobj* elements, edit them, validate
them, and write them back to an element file, preserving comments.

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 39° — Wind SSW at 13 mph. Sky partly cloudy.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaaDExgAKCRBg2/xipKOW
UmK8AJ9+KFBWAaKz2Gp/psGEMDhTxuHyZwCeIApxqDZ1V+QlCaovMkgtFPTIAkQ=
=oxyH
-----END PGP SIGNATURE-----