weewx
add weewxd entrypoint to station registration url
This adds a 'installer' element to the station registry to provide breakdowns of how registered stations chose to install weewx, based on the location of weewx.conf for the running instance.
The updated registration url would have the 'installer=
http://weewx.com/register/register.cgi?station_url=http%3A%2F%2Fwww.example.com&description=My+Little+Town%2C+Oregon&latitude=0.0000&longitude=0.0000&station_type=Simulator&station_model=Simulator&python_info=3.7.3&platform_info=Linux-4.19.0-16-amd64-x86_64-with-debian-10.11&installer=setup&weewx_info=4.5.1
Unfortunately, this is the easy part. The hard part is changing the database and reporting tools on the weewx.com server.
Got Perl?
Perhaps do the instrumentation now and ignore the added field for now, assuming it's benign to the current tools and db, and catch the back-end up later as time and inclination permit ?
perl cgi - wow 1993 just called :-)
oh - the point is that if the backend caught up down the road, you'd have lots of good data in only a week from all the existing 4.6 (?) users who enable the registry, and you wouldn't need to wait til some weeks after a future release to see the benefits of the data.
unless it's not of any interest of course, in which case feel free to close the PR as 'naaaaaah not interested'.
On Mon, Oct 11, 2021 at 4:58 PM Tom Keffer @.***> wrote:
don't see the point in that. Any posted data would just be lost.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/weewx/weewx/pull/705#issuecomment-940525804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAETMKVJLBHPZ3VENXM3MYDUGN2ZXANCNFSM5FY3TM4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- ----- @.*** ----
Good point, although I'm dubious the backend would ever catch up!
Tell you what: we're on the home stretch of releasing V4.6 and I'm reluctant to include new features. How about we revisit after 4.6 is out?
On Mon, Oct 11, 2021 at 5:21 PM Tom Keffer @.***> wrote:
Good point, although I'm dubious the backend would ever catch up!
Tell you what: we're on the home stretch of releasing V4.6 and I'm reluctant to include new features. How about we revisit after 4.6 is out?
No problem. If you want to point me at the cgi code I can take a look at that if you want in the interim.
-- ----- @.*** ----
It's in the "website" repository: https://github.com/weewx/website
See the subdirectory register.
Gawd, I hate Perl.
sorry to be a pedant, but we cannot call this 'installer' - it is simply "location of weewx.conf file". that may or may not be associated with whatever was actually used to install. for example, a weewx-multi site will register as 'unknown', whether it was installed using setup.py or deb or rpm.
also misses anything installed to location other than /home/weewx
better to check the location of the weewxd entry point. if that is /usr/share/weewx then it was a package install.
even better to not infer the installer - just report the location of weewxd. then any support activity can delve into installer method, if necessary.
Sure - makes sense to me. I needed some name so installer came to mind, but it could of course be called anything. Does 'entrypoint' make more sense perhaps ?
If somebody could point me to the schema for the stations db it would be a big help. I'm trying to stand up a LAN-only copy for dev purposes to see if I can get the additions to all the cgi and perl stuff (and the docs) as the code doesn't have that in it as far as I could find. Email is fine.
Changed 'installer' to 'entrypoint' per Matthew. I did a quick test and the existing tools seem to gracefully ignore an extra element in the registration url, but I'll do more testing as I look into the perl code in more detail.
Finally got around to looking at this.
You can't count on the station registry getting invoked by weewxd.
I switched to registering the location of the configuration file, which is more universal, and can also, potentially, yield more information.
Take a look at the branch https://github.com/weewx/weewx/tree/vinceskahan-add_installer_to_registration and see if you like it.
I have not tested.
No preferences at all here, but given Matthew seemingly wanting the opposite in his 0ct-13-2021 comment above, I guess I'd like him to chime in on this one. I don't know if it has any effect on him thinking about things like weewx-multi or the like.
FWIW - the original question I was hoping to answer was 'how do people install the software' since we get so many packaging related questions and people also basically forget how they installed the software rather frequently. Maybe there are more things we might want to add in this one (?)
I'm fine with whatever you guys zero in on, and I can spend some time testing almost certainly once we pin down on what you'd like to finalize on adding...
(thanks for resolving merge conflicts due to this one languishing for a year. It 'did' work without conflicts way back then but I didn't spend the time to keep it conflict-free as weewx moved forward since then)
Your original version tried to infer installation method by looking for very specific paths to the config file. That makes it brittle.
This version simply records the location of the config file, without making any inferrences. That's up to the analysis software on the server.
I'm good with your changes. Hopefully I didn't do anything in my forked branch to lose your edits.
If you get a chance, I'd greatly appreciate it if you could test the changes.
Tests ok for me vs. simulator
- normal setup.py systemd start
- manual invocation vs. /var/tmp/weewx.conf
- manual invocation with weewx.conf location not specified
Last year I recall checking that the cgi gracefully ignores unexpected parameters in the URL so I think this is likely ok to go with. I'll take a pass at the corresponding PR for the website (backend cgi) and update that one's status in that PR.
One testing note - I added a "log.info(_url)" around line 1651 in my local copy to log the URL it generated to syslog so I could compare before+after. I don't know if there's a better way to do that, but it might be worth thinking about having optional client-side logging of the registration URL for times when folks complain they don't see their system in the map.
Thanks Vince.
I modified restx.py to log the URL if debug >= 2. Should work for any uploader, not just the station registry.
After discussion off-line with Matthew, we decided to include the location of the entry point as well as the location of the config file. Commit https://github.com/weewx/weewx/commit/813bec2bab0c3a569a92cebb58df7cb320a90c15
A glitch. Because this implementation depends on adding keys config_path and entry_path to config_dict, when it comes time to do an upgrade they are written out to weewx.conf.
You end up with the head of the file looking like:
...
# Do not modify this. It is used when installing and updating weewx.
version = 4.9.2a1
config_path = /home/weewx/weewx.conf
entry_path = /home/weewx/bin/wee_config
...