Re: [weewx-development] Google Groups Ending Support for USENET

Chuck Rhode writes: > I know Google prescribes various techniques for other mail servers to > AVOID SEEMING TO BE origins of spam, but these are onerous or not > available to retail customers. Not to defend google, but: They seem to expect SPF and DKIM, and I sort both of those into "if you

Re: [weewx-development] Google Groups Ending Support for USENET

Vince Skahan writes: > [...tl;dr;] > > Actually I did read your post. Twice. And I'm totally lost what you point > is there. > > FWIW, I use Safari on a Mac to post and followup. I try to quote stuff to > hopefully look ok in the reply. Most times it works. Some times it > doesn't bec

Re: [weewx-development] WU Updates and DNS

I agree with Ryan and Joel. It is normal to call gethostbyname when you need it, and if that's an issue the user should set up a caching resolver. It is a likely source of bugs and a definite source of complexity to have another caching layer in the daemon. Besides, WU should support mqtt with a

Re: [weewx-development] Re: V5.0 release candidate available

"'Cameron D' via weewx-development" writes: > My assumption would be that any derivable value that you want to plot > should be a column in the database. Even if you could speed it up, the > calculation it would need to be by a factor approaching 100 to be a useful > choice. > I think that us

Re: [weewx-development] Re: V5.0 release candidate available

Tom Keffer writes: > Very useful data, Cameron. > > Right now, if you want one year's worth of say, windchill, and it's not in > the database, it is calculated one record at a time. For a 5 minute archive > interval, that's 100k+ database accesses. It's a general algorithm, but > it's slow. > > A

Re: [weewx-development] V5.0 release candidate available

Tom Keffer writes: > Hmmm, that didn't work. If you list "wheel" as a dependency, pip isn't > smart enough to install it first before attempting the others. So, you get > the same error. Is it the case that new enough pip installs it? I just did $ virtualenv-3.11 FOO created virtual envi

Re: [weewx-development] Re: V5.0.0b17 available

"pa...@pauland.net" writes: > Pondering more on weewx set up creating > /etc/logrotate.d/weewx > /etc/rsyslog.d/weewx.conf > /var/log/weewx > While these are all ineffectual as /var/log/weewx/weewx.log will never be > created, there harmless and silently ignored. Generally, all of this should b

Re: [weewx-development] Re: PostgreSQL support, which branch to target?

matthew wall writes: > the schema uses mixed case, and the column names are not consistent > (some are snake_case, some are camelCase). these names are used > directly (case-sensitive), throughout the weewx code, and particularly > in the templates and plots. the problem i encountered when doin

Re: [weewx-development] writing an extension to broadcast JSON

Vince Skahan writes: > I'm thinking of writing an extension that emits a JSON broadcast of weather > station data in a format that matches the WeatherFlow UDP API. The reason > I'm asking is that there's a very nice project called PiConsole that uses a > pi3 or pi4 to drive a pretty slick lo

Re: [weewx-development] error: can't find Rust compiler

Lucas Heijst writes: > Tom, Vince and Greg, > > For users with a limited knowledge of Linux the installation of weewx > should be a few (simple) installation steps as it always was before. Yes, but you are blurring: Things weewx depends on decide to use languages that are not compatible wi

Re: [weewx-development] error: can't find Rust compiler

Vince Skahan writes: >> On Monday, May 29, 2023 at 10:58:48 AM UTC-7 Joel Bion wrote: >> Should a 64 bit O/S be a WeeWX prerequisite? > No. The only prerequisite should continue to be compatible python things. Indeed, but with rust, you end up with an implicit requirement that you cross build,

Re: [weewx-development] error: can't find Rust compiler

Lucas Heijst writes: > The weewx installation stops with error "can't find Rust compiler", see > attachment I am far from an expert, but your choices are basically: install the rust compiler, or find all the projects that decided it was ok to depend on rust, file bugs that they shouldn'

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Not really weewx, but beware private pip repos: https://pytorch.org/blog/compromised-nightly-dependency/ -- 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 we

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

That looks flexible enough. I guess the package will just have the pip and then someone will create a station, perhaps multiple someones on the same box with different serial/etc. ports (unlikely I know). Thanks for the discussion. -- You received this message because you are subscribed to the

Re: [weewx-development] WeeWX docs

I think the big thing is for the tooling to be Free, to not have nonportable language dependencies (haskell, rust) and to already be widely packaged. I think this fits the bill - looks like just python and I built and installed it from pkgsrc with no hassles. -- You received this message because

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Tom Keffer writes: > OK, now I get you. > > It may be tradition, but the trend has been towards avoiding root installs, > which by necessity require installation in user directories. > > In any case, if you want the more traditional approach, there's always an > apt install. Root vs not is about

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Tom Keffer writes: >> I think 'weewx-data' is an artifact of the previous install and would be >> separate config and state were we starting fresh. > > I'm having a hard time decoding what you're trying to say. Can you be more > specific? In the context of packaging, a package has code and other

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Greg Troxel writes: > It seems obvious that extensions should use the same pip strategy and > depend on weewx. Yes, need to cope until they are updated, but need to > push them to align. my opinion about a basic rule: in a pip venv, everything is managed by pip. -- You received thi

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Tom Keffer writes: > 1. The document outlining the goals and strategies of V5 has been updated. > https://github.com/weewx/weewx/wiki/Version-5 IMHO python >= 3.8 is good enough for a few months from now but I don't use Laggard Term Stable :-) dropping <= 3.6 and 2.7 is good. > 2. New documen

Re: [weewx-development] What is the average lifespan of the µSD card in a PI, and why not another paradigm?

PC writes: > According to your experience, what is the average lifespan of the µSD card > in a PI. I think for example of the images which are crushed every 5 > minutes, which causes, as you know, premature wear. > Can we imagine a paradigm shift: I am only a self-taught programmer, but > pe

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Tom Keffer writes: > Greg: The package installers would continue to install to /etc/weewx. For > those who want something that "just works" that continues to be a good > idea. However, there is a disadvantage: it requires sudo to install and > edit. Many of us also prefer to have everything unde

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

Vince Skahan writes: > On Tuesday, November 8, 2022 at 10:34:19 AM UTC-8 Tom Keffer wrote: > >> Our new "second step" tool would use importlib.resources >> to find >> package data, which is still supported (indeed, *encouraged*), and

Re: [weewx-development] Re: Some wee_ctl thoughts from the draft wiki page

matthew wall writes: > where the conf lives is not yet clear. for apt/yum it is clear - they live > in /etc/weewx. for a python install, we are considering ~/weewx of the > user who created the station instance (not necessarily the same as the user > who installed weewx). from a support po

Re: [weewx-development] Some wee_ctl thoughts from the draft wiki page

Vince Skahan writes: >- in the new vision's future, would we have one weewx.conf or a bunch of >them that are either additive or with some superseding rules. Again, >thinking about how puppet and splunk do things, which can get really >confusing in figuring out why it did wha

Re: [weewx-development] config file quoting and whitespace changes during upgrade

Joel Bion writes: > One other question: is it possible to ask the user, instead of running > setup.py, to run a script located in the weewx 'top level directory' that > does the following: (a) uses the new form Python install/upgrade (b) then > runs separate code (even if it's in python) to upgr

Re: [weewx-development] config file quoting and whitespace changes during upgrade

Tom Keffer writes: > I hear you on the complexity of Python packaging. I've been using node for > a few years now and they have done a much better job. Unfortunately, the > Python gods have decided to create a backend standard (PEP 517 > ), and then rely on a 3

Re: [weewx-development] config file quoting and whitespace changes during upgrade

Tom Keffer writes: > The problem is not the configobj format, it's the future readonly nature of > Python installs. The config file (and skins) are considered "data", and the > only way to include "data'' is within a Python package. That package might > be in a zipfile or Python egg, hence its r

[weewx-development] config file quoting and whitespace changes during upgrade

(I have been running WeeWX since the very end of 2017, and updated a few times. I'm building with setup.py on NetBSD, but I'm quite used to python.) There is some config file auto update/merge stuff. My usual practice is to keep my config file matching the default example in the source code, e

Re: [weewx-development] Data continuity through power outage

"morr...@gmail.com" writes: > Gah, on further thought, this concept seems to be fighting against the > design of weewx. Might be better to put everything, including weewx, on a > machine that is backed up by battery. I don't really see it as fighting the design. Yes it makes sense to have a

Re: [weewx-development] Data continuity through power outage

"morr...@gmail.com" writes: > We're just recovering from Hurricane Fiona here. My weewx server was off > for 14 hours becasue of the power outage. > > I'm thinking of caching readings in my DIY Moteino based weather station, > or the base station which accepts data from it via 915MHz radios, a

Re: [weewx-development] rtldavis not getting any package

[I'm answering here, but really this belongs on -users!] Guido Cioni writes: > I have installed rtldavis as advised > here https://github.com/lheijst/rtldavis and also took care of compiling my > own librtlsdr as advised > here > https://groups.google.com/g/weewx-development/c/L5Lt8x87I_s/m

Re: [weewx-development] Aggregated Values in MQTT Output

Karen K writes: > The general way of WeeWX is to think of an archive interval to be open at > the left end and closed at the right end. This is because it records the > readings of the last 5 minutes. Thanks; I was unclear on that and (] seems sensible. > Actually if you show yesterday rain

Re: [weewx-development] Aggregated Values in MQTT Output

Karen K writes: > There is a comment in restx.py saying: > > # NB: The WU considers the archive with time stamp 00:00 > # (midnight) as (wrongly) belonging to the current day > # (instead of the previous day). But, it's their site, >

Re: [weewx-development] Sieverts (Ionizing Radiation)

"'Cameron D' via weewx-development" writes: > " ionizing_radiation " would be an obvious and unambiguous choice. I guess there are two observations, one is counts/s and the other some estimate of uSv/s. But given the weewx approach, I think it makes sense to let the input device attempt to es

Re: [weewx-development] Sieverts (Ionizing Radiation)

Clay Jackson writes: > Here's one a bit "off the wall" - I happen to live near Hanford, WA (2nd > largest radiation cleanup site in the world, behind Chernobyl) and I'm also > interested in "Space Weather". So, when mightyohm (www.mightyohm.com) put > their Geiger counter on sale last year,

Re: [weewx-development] Interface a MightyOhm ionization counter to weewx

Glenn Godden writes: > I would like to interface a MightyOhm ionization counter ( > https://mightyohm.com/blog/products/geiger-counter/ ) to weewx to report on > cosmic rays, the ionization counter has both a SPI ASCII and pulse output. > Has > anyone made this interface? Guidance and inputs

Re: [weewx-development] another deb11 deprecation warning

Vince Skahan writes: > I checked /etc/os-release for what version they reported being based on. > The following have a /var/run => /run symlink. > >- centos 7.9 >- almalinux 8.5 (rhel-8-like) >- ubuntu 18.04 LTS and newer >- raspbian based on deb-10 and newer >- deb-11 >-

Re: [weewx-development] Re: meta: spam filtering woes on weewx-devel

Bill Richter writes: > gmail irritates me to no end. Along with a lot of other spam filters who > fail to check a domains email reputation stopping once they see a dynamic > IP. As best I can tell, all I did on that link was cut and paste that > change to apply to my version of beta3. I di

[weewx-development] meta: spam filtering woes on weewx-devel

I just started having a lot of messages from weewx-devel land in spam. It took a bit to track it down, but apparently somehow this got rewritten (I think perhaps by Bill's client) from > The transmitter value was fixed in commit 378cd18 >

Re: [weewx-development] Licensing question

"sbar...@gmail.com" writes: > I have made my sds-011 extension as a weewx service. However, I based the > extension from matthewwall sds011 driver. Original code was GPL v3, and I > changed it to MIT. I cannot speak for mwall, and IANAL, I'm not your lawyer, TINLA, etc. But I frequently rant

Re: [weewx-development] New service weewx-knx

It's great that you are extending weewx and contributing. I want to suggest something else you might want to look into, although it's more complicated. weewwx excels at dealing with weather station hardware converting/regularizing weather data storing weather data for the long term maki

Re: [weewx-development] Re: GW1000 driver

George Alfert writes: > I think what people should realize is that there are 3 methods to get data > from the GW1000. > > 1. Customized server upload WU protocol > 2. Customized server upload Ecowitt protocol (this is not the same as API) > 3. GW1000 API (nothing needs configuring in WS View) D

Re: [weewx-development] GW1000 driver

Thanks for writing this and sharing -- this is particularly interesting to me as I am about to give advice to someone on which station to buy in the $200-$300 range. I have developed the driver without direct access to the API so I am sure there will be some issues with it, most likely to do

Re: [weewx-development] Example of how to add second data source that gets data via loop record

Earl Baugh writes: > I read the section on Adding a Second Datasource, but that doesn't quite > match my use case.I'm feeding all data into the system via the > WeeWX-MQTTSubscribe add > on. I have an outside program that is pulling data

Re: [weewx-development] (Slightly OT) Looking for Beta Testers for a iOS Weewx Weather app

Meryon Montgomery writes: > I've been using Weewx for a while now, and I decided that I wanted a native > iOS app to check my weather data. Firstly as a reason to get me back into > coding after a couple of decades and just being curious to see if I could > do it. I’ve now got it to beta testi

Re: [weewx-development] Re: Somewhat OT - Split RTL_433 data

Vince Skahan writes: > On Tuesday, May 19, 2020 at 4:35:41 PM UTC-7, cl...@n7qnm.net wrote: >> >> So – has anyone else run into this problem and maybe found an “elegant” >> solution? Or, perhaps not-so-elegant? I suppose I could hack rtl_433 and >> conditionally direct SOME of the traffic to

Re: [weewx-development] Re: Package weewx like other python projects

Till Maas writes: >> The downside of option-2 is what would we do if a security vulnerability > > Another downside, which is what led me to start the discussion, is that > this makes weewx different from other Python projects which makes my > generic Python/Linux experience less useful because e

Re: [weewx-development] os_uptime incorrect on 4.0.0/python3.7 on macos

Tom Keffer writes: > If we can't find a way around this, we're just going to have to disable the > Mac system uptime tag. Perhaps initialize uptime, before any code is run, to None to mean "we don't know", and then just omit reading/using it when None, which could handle systems that can't get u

Re: [weewx-development] Re: Package weewx like other python projects

Vince Skahan writes: > It's not a broken packaging system, it's operating system differences and > trying to use one package to handle all os variants+versions with one > package. I've battled this for 15+ years in $work. > > A python app packaged in rpm format would run on centos 5, 6, 7, 8 ju

Re: [weewx-development] Re: Package weewx like other python projects

Tom Keffer writes: > Vince, you're the Docker expert. Would it solve some of these problems? Is > it widely available? I don't think docker is adequately portable; it would have to run on every single posixy system that is currently capable of running python. And weewx really isn't that complic

Re: [weewx-development] Re: Package weewx like other python projects

Vince Skahan writes: > Not naysaying, but every time we ask a user to read and think and do > something based on their particular os, there 'will' be 'many' people who > don't do so. To me, this is a clue that the only reasonable approach for people that are not trying to develop weewx, is to

Re: [weewx-development] Re: Package weewx like other python projects

Tom Keffer writes: > If I install using > > *pip3 install ansible --root=/home/ansible --prefix=""* > > I get > > /home/ansible > ├── bin > │ ├── ansible > │ ├── ansible-config -> ansible > │ ├── ansible-connection > │ ├── ansible-console -> ansible > │ ├── ansible-doc -> ansible > │

Re: [weewx-development] weewx with multiple stations supported by a driver

Vince Skahan writes: >> when you talk about influxdb, do you mean still using weewx to >> >> get data from station >> put into influxdb >> >> get from influxdb and make graphs, as in skins >> >> ? > > I use influxdb to do data aggregation and comparison locally on the LAN, > comparing

Re: [weewx-development] weewx with multiple stations supported by a driver

Vince Skahan writes: > Just reading between the historical lines a little, my interpretation has > always been that a driver 'interfaces' weewx with a weather station console > or equivalent, while a service 'extends' weewx to do something it doesn't > do in the core software. That's true, bu

Re: [weewx-development] weewx with multiple stations supported by a driver

Till Maas writes: > A weewx weather station consists of one driver and possibly multiple > services. It supports multiple temperature/humidity sensors but only one > rain/wind sensor. I don't think that's quite right. "weather station" there means "pile of stuff that weewx gets data from". The

Re: [weewx-development] weewx with multiple stations supported by a driver

Till Maas writes: > So a PC supports probably several Master Bricks, each master Brick > several Outdoor Weather Bricklets (they contain the wireless receiver) > or other sensors and each Outdoor Weather Bricklet supports 255 wireless > sensors and 255 wireless weather stations. The weather stati

Re: [weewx-development] Re: Package weewx like other python projects

Tom Keffer writes: > On Wed, May 6, 2020 at 6:30 AM Greg Troxel wrote: > >> Tom Keffer writes: >> >> > In fact, I would appreciate it if you could point me to any non-trivial >> > application that pip installs. I couldn't find any. Just libraries. &g

Re: [weewx-development] Re: Package weewx like other python projects

Tom Keffer writes: > In fact, I would appreciate it if you could point me to any non-trivial > application that pip installs. I couldn't find any. Just libraries. home assistant which is sort of like weewx, but more complicated. My home assistant install, via pip in a venv, has 119 modules. >

Re: [weewx-development] Re: Package weewx like other python projects

mwall writes: > it would be nice if this actually worked. for example, python3-cheetah is > available in debian10 but not in debian9. python-pyserial and python-pyusb > are not available in centos7. so there are some operating system releases > in which you must do a 'pip install' (debian9)

Re: [weewx-development] Package weewx like other python projects

Chris Alemany writes: > I was actually looking at the “brew” system, which is Linux and MacOS > friendly, just yesterday to see how packages were created in that > system. It might be a good candidate? I have said "packaging system", by which I mean every Linux distribution pkgsrc (10+ oper

Re: [weewx-development] Package weewx like other python projects

Vince Skahan writes: > Problem is that every os, and every packaging system, expect 'their' paths > to be 'the' standard. There are some very slight variations, but the venerable BSD hier(7) was changed fairly little into FHS. And, autoconf is the ur-typ of how this is done, with --etcdir and

Re: [weewx-development] Package weewx like other python projects

My $0.02, coming from packaging many things: People who develop a particular package are very used to how it is built, and so more or less however that works is fine for them. People that are coming to something new, or packaging systems that have say 20K packages, would like to see a sma

Re: [weewx-development] Re: python3

Cat22 writes: > Here is the result of the bug I filed which has been closed by them as "wont > fix": > "Yes, we are removing all python2 packages from the distribution. > If weewx maintainers haven’t noticed switch to python3 for eleven years, than > you should complain with them." Up to you

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

mwall writes: > we started a postgres adapter years ago. it never made it into weewx core. Sorry -- I use a lot of programs and my memory was that weewx supported postgres. I have used it for various things over the years including one project that had frequent crashes due to laptop batteries

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

Glenn McKechnie writes: > It's not weewx increasing in CPU usage, it's the CPU usage for > mariadb. Check on your Synology NAS. I wonder if people have tried postgresql. (I'm still on sqlite.) -- You received this message because you are subscribed to the Google Groups "weewx-development" gr

Re: [weewx-development] WeeWX 4b15 setup error

Thomas Keffer writes: > But, you're right: generally Python's setup.py does install into > /usr/share, /etc, and so on. However, our assumption, good or bad, was that > users would use apt-get (or equivalent) if that's what they wanted. Fair enough, but I would expect a packaging system to use s

Re: [weewx-development] Re: [weewx-user] 4 beta test report

Thomas Keffer writes: > OK, so we've isolated the issue to a problem with how NetBSD implements > time.mktime(). I don't think it's a problem in the implementation, just not matching the weewx code's beyond-standards expectation. As I understand it, an error return for times that do not exist i

Re: [weewx-development] Re: [weewx-user] 4 beta test report

I get Starting datetime is 2020-03-08 01:00:00 Represented as a time tuple, this is time.struct_time(tm_year=2020, tm_mon=3, tm_mday=8, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=68, tm_isdst=-1) After adding an hour, the resultant datetime is 2020-03-08 02:00:00 Represented as a timetuple

[weewx-development] Re: [weewx-user] 4 beta test report

Greg Troxel writes: (Earlier, on weewx-user, I posted that I was seeing a backtrace from v4beta (recent master). I'm following up here now that I've read the code and have something perhaps useful to say.) > Traceback (most recent call last): > File "/usr/weewx/bin/

Re: [weewx-development] state of the git repo, master/development considered very awkward

Vince Skahan writes: >> So basically what's missing is a branch ref stable-3-9 which started out >> pointing to master as soon as it became v3.9 time, is advanced along >> commits on master intended for v3.9.next, and now points to 0ecd4fed. >> > Totally lost. There 'is' no stable N-1 branch.

Re: [weewx-development] state of the git repo, master/development considered very awkward

Vince Skahan writes: > Greg - still missing what you're looking for that you can't already do. > >- git pull >- git checkout -b v3.8.2 (create a local branch off a release tag) Sorry, I misread that the first time, so my previous-message comments about that didn't make sense. That c

Re: [weewx-development] state of the git repo, master/development considered very awkward

Thomas Keffer writes: > The merge was intended (and usually is) done just before release. It was > our intention to do an immediate release, but we had some delays. > > WeeWX may be a bit different from other software you are used to. We > *never* support old releases. Either you upgrade, or you

Re: [weewx-development] Re: state of the git repo, master/development considered very awkward

First, thanks to you and Thomas for replying; I was delaying on purpose to see if anyone else commented happened and think about it. Vince Skahan writes: > Interesting post. Sounds like you want some kind of semi git-flow kind of > thing except with long-lived minor-release extra level of int

[weewx-development] state of the git repo, master/development considered very awkward

I have been following the messages about 4.0 alpha/beta stuff with interest, expecting to get around to testing some day. I just did a git remote update, and was surprised to find that master, which had previously been the stable branch, now contains 4.0beta (loosely speaking). I must have missed

Re: [weewx-development] Supporting Columbia Weather Systems MicroServer hardware?

Not directly answering your question, but: I would look into the MQTT extension -- which publishes json to MQTT and doesn't do at all what you want. But it probably has some code clues. More usefully I would look at https://github.com/bellrichm/WeeWX-MQTTSubscribe which does not do the web/j

Re: [weewx-development] Re: continuation of discussion on wxMesh MQTT

KSKENYON writes: > I'm stumped. wxMesh.py v0.2 runs fine with b7 and python3 after a few > small tweaks. > > Now matter what or how I send data from mosquitto I get this weewx error > about being unable to convert to float. I've tried every format I can > think of on the publish line and eve

Re: [weewx-development] A question on end_archive_period_ts

Pat writes: > I don't know why, but I'm fascinated with this small bit of code. I always > wondered how the archive interval runs on the 5th minute reliably (on a > vanilla install). It doesn't matter when you start weewx, it'll run on that > 5th minute interval. If I start weewx at 8:31, I'll

Re: [weewx-development] weewx 4 on mac

Thomas Keffer writes: > I must be missing something, and I am most definitely not a Mac expert, but > my laptop doesn't even have an /opt directory. It doesn't, and macs don't have /home by default either (mac uses /Users/$USERNAME instead). But either /opt or /home can be created, even with SI

Re: [weewx-development] weewx 4 on mac

Chris Alemany writes: > Yes 'man hier' is available under macOS 10.14.6 > > /opt is not an unusual place to put open source stuff on Mac, it is > what wview used as well. However, I would lean toward /var as well as > Vince suggested or even put the logs within the user defined area (I > have mi

Re: [weewx-development] New alpha version

As running this on one's main station seems ill advised at this point, it would be interesting to have a recipe for posting MQTT from a production system and ingesting MQTT on a dev system. That doesn't test the drivers, but it does exercise a lot (including implicitly OS issues). I realize I can

Re: [weewx-development] Re: weewx and packaging systems

Thanks. I do understand how packages work; it was just that I have not run into a thing like weewx that has a functioning build/install system, but where one isn't supposed to use it when building a package. In all the rest of the things I've dealt with (probably over 100), the package config fil

Re: [weewx-development] Re: weewx and packaging systems

mwall writes: > packages are typically downstream from the source. of course, if we are > doing things in the source that make packaging difficult, we'll try to > address that. Thanks to you also for taking the time to write back to me. Between your and Vince's I feel like I understand the b

Re: [weewx-development] Re: weewx and packaging systems

Vince Skahan writes: > Huh ? > > Packages have been available for debian(ish) and redhat(ish) operating > systems for a number of years. Those packages install the > prerequisite/corequisite packages that are needed to make weewx work and > install things where those operating systems install

[weewx-development] weewx and packaging systems

(I've been running weewx for about 1.5 years under NetBSD on i386 and then RPI3, using pkgsrc to provide the dependencies.) I created a pkgsrc package for weewx in pkgsrc-wip, and there are some awkward things about it. Part of the reason was to capture the dependencies to avoid having to manuall

Re: [weewx-development] Re: [patch] station.py support OS uptime for FreeBSD 11

I meant to get the os name and switch on that, and only try methods appropriate for that os.

Re: [weewx-development] Re: [patch] station.py support OS uptime for FreeBSD 11

Jon Marnock writes: > I know this is an ancient thread, but I just got weewx up and running on > OpenBSD and found the FreeBSD kern.boottime thing didn't work for system > uptime because the sysctlbyname doesn't exist there. The try block that has a comment about FreeBSD works on NetBSD also,

Re: [weewx-development] Re: Receiving Davis Vantage data with RTL-SDR dongle and program rtldavis

ljm.hei...@gmail.com writes: > I don’t know. What we do know by now is that the well known and proven to be > good frequencies (of RFM69) are not working in program rtldavis. > We can do one of two things to solve this. > 1. Find out what the problem is and fix it. This is not easy and a thorou

Re: [weewx-development] Re: Receiving Davis Vantage data with RTL-SDR dongle and program rtldavis

nls writes: > As mentioned earlier, the frequencies were sniffed in original VP2 consoles > (you can find the posts about that in wxforum threads). They're the GFSK > center frequencies, no IF. The "RFM69 frequencies" just mean the ones > programmed into the firmware of small Arduino clone based

Re: [weewx-development] Re: Receiving Davis Vantage data with RTL-SDR dongle and program rtldavis

ljm.hei...@gmail.com writes: > I found a correlation formula between the RFM69 frequencies and my EU > trial-and-error frequency set. > > rtldavis frequency = (RFM69 frequency -4000) * 1,048319523 > > These calculated rtldavis frequencies DO work! > > Excel gave the following equation: y = 1.

Re: [weewx-development] Re: Vantage LOOP2 packets (for THSW index)

Thomas Keffer writes: > Not only is THSW used in the US, it was invented here by Robert Steadman 40 > years ago. > > Here are papers on how to calculate it using tables > , > and using formulas >

Re: [weewx-development] Re: Vantage LOOP2 packets (for THSW index)

Deborah Pickett writes: > Something that was brought up with me off-list, but which I am not equipped > to answer: THSW index is a proprietary Davis calculation, and so far the > schema has been unpolluted with vendor-specific terms. What if another > vendor invents an almost-but-not-identica