Configuring services

[bell...@gmail.com]

In the 4.5 years since I released MQTTSubscribe, I’ve leaned so much about WeeWX (and continue to be impressed with how well it is designed and implemented). It is now time for me to update and improve the process of configuring MQTTSubscribe. MQTTSubscribe can be a bit complex to configure (that is a whole different discussion). When installing as a driver, one can be prompted with configuration options. There is no such mechanism for services (and skins), that I know of.

I’m thinking of writing some code similar to wee_config (weectl/station) to allow a person to configure MQTTSubscribeService the same way one can configure MQTTSubscribeDriver. Has anyone else done something similar? Any obvious pitfalls I’m missing?

Thanks. rich

[Tom Keffer]

Hi, Rich

If you use MQTTSubscribe as a driver, there is an existing mechanism --- the configuration editor. Unfortunately, there is not much documentation on how to use it (well, actually, there is no documentation), but if you look at existing implementations (such as for the Vantage driver), you can probably figure it out.

There is no analog for services, although that would not be a bad idea.

-tk

--
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 on the web visit https://groups.google.com/d/msgid/weewx-development/b8cc63a0-e08d-4eb4-87e0-c7eca15850ecn%40googlegroups.com.

[Vince Skahan]

Some kind of a general purpose 'add/delete/edit' function for the rather complicated configobj format of weewx.conf would be a huge help for folks who want to automate installation and configuration.  It's kinda impossible with any devops tool I've found to do things like enabling one particular element when they all have the same enable=true/false key/value pair.

Rich - one way you might think about is simply putting a fully commented out example stanza into weewx.conf when you install as an extension.   I worked a couple years ago with Pat from Belchertown to do that with his skin, as most people were getting lost in the configobj hierarchy and zillion configurable items for that skin in particular.   All we did was add a bunch of commented out items into install.py for the skin.  Take a look at https://github.com/poblabs/weewx-belchertown/blob/master/install.py - it should be pretty obvious.

[bell...@gmail.com]

Tom and Vince, thanks for thoughts. Part of the ‘problem’ is I have separate config sections for the driver and service. They have essentially the same information. At this time about the only reason to have them separate is to allow running as both a driver and service. And about the only reason to do this, is to connect to different brokers.
I currently minimally leverage AbstractConfEditor for driver installation and configuration and a medium commented default weewx.conf in install.py for service invocation. I sometimes forget to update one or the other…
I think I landed on the approach of shipping an example weewx.conf and update MQTTSubscribe to use it to configure itself. It would allow something like this
wee_extension —install development/MQTTSubscribe
edit mqttsubscribe.example.conf
MQTTSubscribe.py simulate service weewx.example.conf
Debug as necessary
MQTTSubscribe.py configure service —update-from weewx.example.conf weewx.conf
Restart weewx

Later in time
MQTTSubscribe.py configure service —export weewx.updated.conf weewx.conf
edit mqttsubscribe.updated.conf
MQTTSubscribe.py simulate service weewx.updated.conf
Debug as necessary
MQTTSubscribe.py configure service —update-from weewx.updated.conf weewx.conf
Restart weewx

I'll also have a --replace-with option and possibly an --add-from. The --replace-with would replace the whole MQTTSubscribe section, providing a poor man's delete. The add-from would only add any missing misinformation

I’m still working out/thinking about how much I want to support interactive configuring for complex, nested, etc. configurations.

I’m also thinking about what type of configuration validation I might be able to add.
rich