I purposely avoided a tool such as wviewmgmt for the reasons Matthew outlined as well as two others.
1. It requires installing a webserver, so now the mission of a newbie becomes getting a webserver running (although with the the introduction of nginx and lighttpd this isn't so bad as it used to be). 2. I really, really, *hate* the idea of an application that monitors the status of weewx, restarting as necessary. WeeWX should just run and not crash. Let's put our efforts into engineering it properly so it doesn't need a monitor. -tk On Mon, Nov 20, 2017 at 12:34 AM, Rod in Edm <[email protected]> wrote: > Yup, I get all that, and was actually thinking about a standalone mgmt > tool that would replace some of the manual editing, just some way to enter > the basic stuff into weewx.conf without hand-editing the file. At this > stage I'm just kicking tires, and asking where the first set of limits are > to what's possible. Thanks for the ideas and considerations to ponder. > > > On Sunday, 19 November 2017 23:07:17 UTC-7, mwall wrote: >> >> >> >> On Sunday, November 19, 2017 at 11:11:38 PM UTC-5, Rod in Edm wrote: >>> >>> Am I missing something that would prevent such a project, or make it >>> difficult? Or is this effort already underway by you, Tom, or the weewx >>> user-base? I appreciate expanding the app may not be in the cards, as >>> doing so might make it bigger and slower than your original plan had in >>> mind. >>>> >>>> >>>> >> a gui for managing weewx would be nice, but it should never be part of >> weewx, imho. you will never be able to write a gui that is as expressive >> as the configuration files. however, one could fairly easily write a gui >> that could robustly manage the basics, and without breaking with every new >> weewx release. >> >> the gui will need a way to communicate with weewx. doing that >> cross-platform is not difficult, but definitely not trivial. one way to do >> it would be a simple weewx service that periodically emits weewx state to >> file(s), or via a restful api. >> >> the basics are easy - latest loop data, n-latest records, which uploaders >> are enabled, which skins are enabled, which extensions are installed. >> >> it gets tricky when you have to do parameters for each extension. or >> even for each driver. you'll need a generic way to map configuration >> parameters to gui elements, without having the gui look like a generic >> config editor. >> >> like i said at the start, i would start with just the basics, and use the >> gui for start/stop/status rather than trying to tweak every possible config >> option through the gui. >> >> btw, i find the wviewmgmt pages rather archaic - mark copied the look and >> feel of the old wrt54 (now linksys) routers, a design that was rather >> cumbersome even in its prime. when i wrote the exfoliation skin for wview, >> i also started a rewrite of the wview configurator and mgmt gui. way too >> brittle! >> >> you could do much more now with a simple bootstrap/jquery interface, or >> even with an openwrt lua-based ui. >> >> m >> > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
