Re: [weewx-development] Re: V4.0.0b4 is up

Fixed in commit d60c154 . -tk On Wed, Nov 27, 2019 at 9:25 AM Hartmut Schweidler wrote: > Hallo Tom > > the driver fousb.py at line addr1 = (address // 256) & 0xff not addr1 = > (address / 256) & 0xff > > the

Re: [weewx-development] Re: V4.0.0b4 is up

Thanks, Hartmut! Alternatively, how about addr1 = (address >> 8) & 0xff which makes the bit arithmetic more explicit. -tk On Wed, Nov 27, 2019 at 9:25 AM Hartmut Schweidler wrote: > Hallo Tom > > the driver fousb.py at line addr1 = (address // 256) & 0xff not addr1 = > (address / 256)

[weewx-development] V4.0.0b4 is up

In the usual place . What we really need is testing of the drivers, particularly under Python 3. If you have something other than a Vantage, please install and check it out! -tk -- You received this message because you are subscribed to the

Re: [weewx-development] error in setup.py after update to commit 4a36cbf

Not a changed requirement. setup.py has import configobj since at least V1.2.0. Maybe earlier. On Tue, Nov 26, 2019 at 9:16 AM P Simmons wrote: > Tom, Vince... gracias, was unaware of the changed requirement. Yo soy un > viejo. > > Paul > > -- > You received this message because you are

Re: [weewx-development] error in setup.py after update to commit 4a36cbf

The source build package uses configobj (so it can check weewx.conf for errors). So, even though you're only packaging, and not deploying, you need configobj installed on your first machine. -tk On Tue, Nov 26, 2019 at 5:53 AM P Simmons wrote: > For my own arcane reasons, I prefer to build on

Re: [weewx-development] Re: Beta of Version 4 is available

Unfortunately, the ImageGenerator does not allow you to use an expression as a data type; only type that appear in the schema, or as an xtype. Defining a new xtype is not terribly hard. It would look something like this (NOT TESTED): File *user/rainet.py*: import weewx.units import weewx.xtypes

[weewx-development] V4.0.0 beta 3 posted

This version incorporates all the fixes for the bugs reported so far! -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

Re: [weewx-development] Re: Beta of Version 4 is available

What is type 'rain-ET'? Is it defined in the schemas for bindings wx_binding and wd_binding? If it is not defined, you will get this error. With beta 3, I've improved the error message. -tk On Sat, Nov 23, 2019 at 6:15 AM Hartmut Schweidler wrote: > supplement > > Die Auswertung aus zwei

Re: [weewx-development] Beta of Version 4 and NOAA-data

At last! Your last email gave me a hint. There was indeed a problem with the METRIC unit system, causing it to use the same unit system as the METRICWX system. Fixed in commit 189ea54 . Thanks for your patience,

Re: [weewx-development] Beta of Version 4 and NOAA-data

Please send us the result of this query: *sqlite3 weewx.sdb* sqlite> *SELECT MIN(usUnits), MAX(usUnits) FROM archive;* -tk On Fri, Nov 22, 2019 at 5:34 AM Hartmut Schweidler wrote: > Hallo Tom, > > my data is stored as METRIC > > Problem: > in den NOAA-Dateien erscheinen die Daten windSpeed

Re: [weewx-development] Beta of Version 4 and NOAA-data

I do not understand what I am looking at. The table: what month is it for? This month? If so, how do I compare it to the data you give for 29.10.2017? I also do not know what units it is in. Also, what was the expected answer? I modified the test suites to create a database in the METRICWX

Re: [weewx-development] Re: Beta of Version 4 is available

You're making it easy! Turns out the vector arithmetic got neglected as well. I think I got it all fixed in commit 073be00 . You can just download xtypes.py

Re: [weewx-development] Re: Beta of Version 4 is available

I am sorry, Hartmut, but that skin has an extraordinary number of custom databases, bindings, templates, search list extensions, observation types, and generators that I can't possibly debug it. You're going to have to get the problem down to something simple, using standard WeeWX facilities.

Re: [weewx-development] Re: Beta of Version 4 is available

I am unable to reproduce this error, nor do I understand the context in which it is happening. Could you please: 1. tar up your report 'CalendarReport' 2. take out any passwords in weewx.conf. You can use the utility wee_debug to do this. Then send them both

Re: [weewx-development] Re: Beta of Version 4 is available

Fixed in commit 178114d . Thanks, Rich! -tk On Tue, Nov 19, 2019 at 7:18 AM Rich Bell wrote: > Should have added, running under python 2. > > On Tuesday, 19 November 2019 10:16:31 UTC-5, Rich Bell wrote: >> >>

Re: [weewx-development] Re: Beta of Version 4 is available

Meaningful. That’s how configObj knows it’s a list, and not a single value. On Sun, Nov 17, 2019 at 11:21 AM Vince Skahan wrote: > Probable nit, but I see a bare comma in the value on the data_services > line in the b1 weewx.conf file. Is that meaningful or just something > extraneous ? > > --

Re: [weewx-development] Re: Beta of Version 4 is available

= Rain (mm/Day) How did you determine this was the problem? -tk On Sat, Nov 16, 2019 at 3:35 PM Thomas Keffer wrote: > Hartmut, try this version of xtypes.py > > -tk > > On Sat, Nov 16, 2019 at 8:47 AM Hartmut Schweidler > wrote: > >> Hallo >> and now by my

Re: [weewx-development] Re: Beta of Version 4 is available

Gary, did you get this under the commit I just did an hour ago? If so, try the development branch now. I reverted that commit. -tk On Sat, Nov 16, 2019 at 4:32 PM gjr80 wrote: > 4.0 is throwing the following for me under python 3.5.3: > > Nov 17 10:27:34 stretch41 weewx[16116] INFO

Re: [weewx-development] Re: Beta of Version 4 is available

Tom, These are problems in meteotemplate, which does not seem to have been ported to Python 3. You'll have to ask the author for fixes (it is not part of WeeWX). -tk On Sat, Nov 16, 2019 at 2:34 PM Tom wrote: > Using Version 4 Beta, Raspberry Pi, and Python3. The Meteotemplate is > giving

Re: [weewx-development] Re: Beta of Version 4 is available

The problem was with old-style schemas (see the upgrading guide if you're interested). Fixed in commit c99c25e . That fixed that problem, but pmon still doesn't seem to be working, at least for me. Perhaps you can

Re: [weewx-development] Re: Beta of Version 4 is available

Hartmut, try this version of xtypes.py -tk On Sat, Nov 16, 2019 at 8:47 AM Hartmut Schweidler wrote: > Hallo > and now by my "StandardReport" an "cumulative" > Nov 16 17:40:27 wetter weewx-weewx[18349] INFO weewx.restx: PWSWeather: > Published record 2019-11-16 17:40:00 CET (1573922400) >

Re: [weewx-development] Re: Beta of Version 4 is available

Thanks, Hartmut! That's exactly the kind of testing we're looking for! Fixed in commit f1c50ae . If you want to fix your version, replace the file /home/weewx/bin/weewx/xtypes.py with this

Re: [weewx-development] Re: Beta of Version 4 is available

lso need all the corequisites for both versions as well ? > > > On Fri, Nov 15, 2019 at 4:09 PM Thomas Keffer wrote: > >> You should be able to install WeeWX under Python 2.7, then run under >> Python 3. Did you have a different experience? >> >> On Fri, Nov 15, 2019 at 4:0

Re: [weewx-development] Re: Beta of Version 4 is available

You should be able to install WeeWX under Python 2.7, then run under Python 3. Did you have a different experience? On Fri, Nov 15, 2019 at 4:06 PM Vince Skahan wrote: > Installed b1 on a pi4 using my patched weatherflow-UDP driver using > python3. Looks ok. >> >> > One thing folks should

Re: [weewx-development] Re: Beta of Version 4 is available

Thanks, Joe. Which version of Python did you use? On Fri, Nov 15, 2019 at 1:46 PM Joe Spears wrote: > Upgraded from the previous alpha version. Its been running well for me > and the upgrade went smoothly. Thanks. > > Raspberry Pi 4 > Vantage Vue > > Joe Spears > > On Friday, November 15,

[weewx-development] Beta of Version 4 is available

Version 4 is now feature complete. There is lots of exciting new stuff, including: - Support for Python 3 - User-defined derived types. - More customizable logging. - Support for Vantage LOOP2 packets. and lots of other, little things. The WeeWX test suites have never been better,

Re: [weewx-development] weewx development

For one of your images you requested 'rainrate.' The correct name is 'rainRate'. -tk On Mon, Nov 11, 2019 at 6:25 AM Hartmut Schweidler wrote: > > > Am Montag, 11. November 2019 15:13:29 UTC+1 schrieb Tom Keffer: >> >> Look at line 8 in weewx.conf. There is a duplicate keyword name. >> >> My

Re: [weewx-development] weewx development

Look at line 8 in weewx.conf. There is a duplicate keyword name. On Mon, Nov 11, 2019 at 5:43 AM Hartmut Schweidler wrote: > Hallo, > > i have Error in __version__="4.0.0a10" > > Nov 11 14:38:51 wee2 weewx-meteo[27232] DEBUG weewx.engine: Loading > service weewx.engine.StdConvert > Nov 11

Re: [weewx-development] Re: Consolidate database interval records?

Nicely done. Thanks, Cameron! On Mon, Oct 28, 2019 at 8:17 AM Cameron D wrote: > Wiki has been written up. *Do not use the code I posted earlier in this > thread *- there are mistakes in it. > > It took a bit longer than expected, as the code needed significant > reworking for various

Re: [weewx-development] Re: Consolidate database interval records?

Very sweet, Cameron! Somebody capture this in the Wiki! -tk On Sat, Oct 19, 2019 at 5:28 AM Cameron D wrote: > Was a bit more painful than necessary, but... > > There are now 3 temporary tables and intermediate calculations. > It might be possible to do it more concisely, but this way gives

Re: [weewx-development] Re: Consolidate database interval records?

Almost. The aggregation type is wrong for some of the columns. You want sum(rain) as rain sum(ET) as ET sum(hail) as hail There is also the problem of windDir and windGustDir. To do these properly, you have to switch from polar notation (scalar, direction) to vector components (xvec, yvec), and

Re: [weewx-development] Re: Consolidate database interval records?

One thing though: you might have to FLOOR the "GROUP BY" clause: create temporary table cons5min as select max(dateTime) as dateTime, usUnits, 5 as interval, avg(barometer) as barometer, avg(inTemp) as inTemp, from archive where interval = 1 group by

Re: [weewx-development] Re: Consolidate database interval records?

The command should work in MySQL as well. On Wed, Oct 16, 2019 at 6:19 PM Pat wrote: > This is great! > > I use MySQL primarily as my source, but frequently flip/flop for testing > various things. I can export the 20,000 rows to SQLite, run this then > import the new rows back to MySQL. Thanks!

Re: [weewx-development] Re: Consolidate database interval records?

Very clever! Thanks, Cameron! Now I know who to email if I get stuck with SQL. :-) -tk On Wed, Oct 16, 2019 at 6:09 PM Cameron D wrote: > Is there any reason you could not just use sqlite's own consolidation > functions... > > create temporary table cons5min as > select max(dateTime) as

Re: [weewx-development] Re: windrun calculations

By "SQL query is the source of all my problems" do you mean the UPDATE? If so, maybe. Somehow there were a lot of bad values for windrun when windSpeed was null. You could try a SELECT for that theory. How did they get there? Beats me. It might be worth searching your archive database and seeing

Re: [weewx-development] Re: windrun calculations

maxsum scans all the daily sums and return the max value. It's useful for figuring out queries like, "What's the rainiest day of the month?" In your case, it would be returning the windrun for the day with the max windrun. I'd replace your UPDATE with: *UPDATE weewx.archive SET windrun =

Re: [weewx-development] Re: windrun calculations

Windrun is an 'extensive' variable, which should be treated similarly to the other such variables, such as rain and ET. So, it should be summed. The total windrun for the year would be $year.windrun.sum. But, I suspect the number will still be big. With your UPDATE, why the restriction for

Re: [weewx-development] Consolidate database interval records?

Yes, it's certainly possible, but you would have to write a Python script to do it. You could start with the transfer_db.py script, located in the examples subdirectory. On Tue, Oct 15, 2019 at 3:10 PM Pat wrote: > Back when I started with weewx in 2015 I had a 1 minute archive interval. > I

Re: [weewx-development] Re: New alpha version

Thanks for your report. That bug was fixed 25 August in commit bfa3b5d . Try the newer alpha version 4.0.0a9 . -tk On Thu, Oct 10, 2019 at 6:17 AM Andy wrote: >

Re: [weewx-development] wview compatibility - time to cut the cord ?

I agree completely that anyone who is coming over from wview has come over. Issue #115 discusses this a bit. I like your generic timeline, although if someone is willing to work on this, I don't see any reason why we can't include an expanded schema in

Re: [weewx-development] Why support Python 2.7?

There are several reasons why we're supporting both: 1. Yes, it's some effort to support both versions of Python, but most of that effort is in the conversion to Python 3. That wouldn't go away. 2. Maintaining more than one code base is a bad idea. There should always be only one

Re: [weewx-development] A question on end_archive_period_ts

With unix epoch time, you don't have to worry about leap seconds. A day is always guaranteed to be exactly 86,400 seconds long. If a leap second occurred during the day, the final epoch time of the day is repeated twice. This makes the math of converting to and from wall clock time super easy.

Re: [weewx-development] weewx 4 on mac

Seems like we've come to consensus. Good thing, because I know next to nothing about the Mac. Implemented in commit c6ff6ed . On Mon, Sep 2, 2019 at 2:59 PM mwall wrote: > > > On Monday, September 2, 2019 at

Re: [weewx-development] weewx 4 on mac

> > But they are just strings, and mwall's comment about aligning the > default setup.py path to /home/weewx to match other platforms is > compelling. > Except, unfortunately, on the Mac, /home is a mounted drive, so we would have to edit /etc/auto_master, unmount, then reboot. Not worth it.

Re: [weewx-development] WeeWX 4.0.0.7a with SDS011 driver

Can you try changing something in your copy of aqi.py? I know the pyserial docs say that if port is None the serial port will not be opened, but let's see if that's true. Change this ser = serial.Serial() ser.port = "/dev/ttyUSB0" ser.baudrate = 9600 ser.open() ser.flushInput() to this ser =

Re: [weewx-development] weewx 4 on mac

I must be missing something, and I am most definitely not a Mac expert, but my laptop doesn't even have an /opt directory. -tk On Thu, Aug 29, 2019 at 12:04 PM Greg Troxel wrote: > Chris Alemany writes: > > > Yes 'man hier' is available under macOS 10.14.6 > > > > /opt is not an unusual place

Re: [weewx-development] weewx 4 on mac

I have no objection to something like this, but the path you've chosen (/opt/weewx/var/run.stderr) seems pretty specific to your system. I'm not a Mac expert. Is there a more generic location it could write to? -tk On Wed, Aug 28, 2019 at 7:13 PM Graham Eddy wrote: > for weewx 4, i would like

Re: [weewx-development] WeeWX 4.0.0.7a with SDS011 driver

I doubt this has anything to do with V4, but I could be wrong. Check to see which process has the port open: *lsof /dev/ttyUSB0* I'm betting there's another process holding on to the port. -tk On Wed, Aug 28, 2019 at 4:19 AM steeple ian wrote: > Tom, > > I am testing WeeWX 4.0.0.a7 with the

Re: [weewx-development] Re: New alpha version

I assume you were trying a systemctl "reload"? If so, I'm not surprised that it wouldn't work with a live thread. I never use it, preferring to kill, then restart. If not, perhaps you could describe what you were doing? systemctl works perfectly on my system. On Tue, Aug 27, 2019 at 2:26 PM

Re: [weewx-development] Re: New alpha version

Thanks, again. I had no idea that Cheetah and ephem had been ported to Python 3, although it seems only this summer in the very recent Debian 10 release. Updated the setup.py install instructions to reflect. Commit aa43108

Re: [weewx-development] Re: New alpha version

Andy, Can you give this version of sdr.py a try under Python 3? It's been ported. -tk On Mon, Aug 26, 2019 at 7:40 PM Andy wrote: > Aug 26 19:37:18 weewx-01 weewx[17727]/INFO weewx.engine: Initializing > weewx

Re: [weewx-development] Re: New alpha version

Thanks, Andy. Looks like Matthew has not done the Python 3 port. I'll submit a PR to him. -tk On Mon, Aug 26, 2019 at 6:15 PM Andy wrote: > root@weewx-01:/home/weewx# python3 ./bin/weewxd /home/weewx/weewx.conf > Traceback (most recent call last): > File "./bin/weewxd", line 64, in >

Re: [weewx-development] Re: New alpha version

Stop your weewx daemon, then just run it right out of the directory. *cd /home/weewx* *python3 ./bin/weewxd weewx.conf* -tk On Mon, Aug 26, 2019 at 6:09 PM Andy wrote: > I will but have to figure out how, virt env? > > On Monday, August 26, 2019 at 5:39:56 PM UTC-7, Tom Keffer wrote: >> >>

Re: [weewx-development] Re: New alpha version

Thanks, Andy. Did you try it under python3? On Mon, Aug 26, 2019 at 5:13 PM Andy wrote: > > > On Saturday, August 24, 2019 at 5:53:39 AM UTC-7, Tom Keffer wrote: >> >> Test, test, test! Especially on devices other than Vantage. >> >> -tk >> > > OK this is running with the sdr driver, vmware

Re: [weewx-development] Logging in python3 and wx2013

Thanks, Hartmut! Turns out there were several calls to the non-existent log.notice(). Fixed in commit bfa3b5d -tk On Sun, Aug 25, 2019 at 2:54 AM Hartmut Schweidler wrote: > Hallo in > > qc.py line 61 is "

Re: [weewx-development] Re: New alpha version

Well... *somebody* can research it, but it won't be me. :-) I'll just go with space delimiters. No slashes. On Sat, Aug 24, 2019 at 6:21 PM mwall wrote: > > > On Saturday, August 24, 2019 at 8:15:19 PM UTC-4, Vince Skahan wrote: >> >> >> The log format surprised me a bit: >> >> Aug 24 16:00:18

Re: [weewx-development] Re: New alpha version

gt; thoughts. > > > > On Sat, Aug 24, 2019, 5:25 PM Thomas Keffer wrote: > >> You can change the log format to anything you want with a [Logging] >> section in weewx.conf, but I'm open to getting the default right. >> >> What is the significance of [W

Re: [weewx-development] Re: New alpha version

You can change the log format to anything you want with a [Logging] section in weewx.conf, but I'm open to getting the default right. What is the significance of [WEEWX.INFO]? That INFO is part of some sort of WEEWX domain? -tk On Sat, Aug 24, 2019 at 5:15 PM Vince Skahan wrote: > On

[weewx-development] New alpha version

I've posted a new alpha version of WeeWX V4. Find it at http://weewx.com/downloads/development_versions/ This version uses a new logging package, supports LOOP2 packets for Vantage stations, wunderfixer works with the new WU download API, and, of course, supports Python 3. This version is almost

Re: [weewx-development] Logging by Python

OK. Try it now. On Sat, Aug 24, 2019 at 5:03 AM Thomas Keffer wrote: > Yes, now I remember... > > Unfortunately, the Python logging facility does not honor the process > name. That is why I made it an optional parameter to the logging set up. > > Let me experiment a bit...

Re: [weewx-development] Logging by Python

Yes, now I remember... Unfortunately, the Python logging facility does not honor the process name. That is why I made it an optional parameter to the logging set up. Let me experiment a bit... -tk On Sat, Aug 24, 2019 at 4:41 AM Hartmut Schweidler wrote: > Hallo, > > die Version > > weewxd

Re: [weewx-development] WU wind speed and wind gust graph issue with rapidfire - would LOOP2 packet resolve it?

Praveen, I think Hartmut was merely reporting on whether LOOP2 works. You can give it a try! If you know how to use git, just clone the WeeWX repository, then run weewxd directly out of the repository, using your old weewx.conf file as the sole command line parameter. No need to install

Re: [weewx-development] Logging by Python

Thanks, Matthew! Good to know it already exists. On Sat, Aug 24, 2019 at 12:10 AM mwall wrote: > > we already have the log-label option. it must be specified when weewxd is > invoked. for example: > > weewxd --log-label weewx-cmon > > weewxd --log-label weewx-vantage > > then use 'weewx-cmon'

Re: [weewx-development] Logging by Python

Presently, all log entries are identified by "weewxd". As I understand it, you are running several instances of weewxd simultaneously, and want a way to distinguish between them in the log. Is that correct? If so, we could put an option in weewx.conf that would set the process name. Something

Re: [weewx-development] Debugging Cheetah

If you're going to do comparisons, you probably want the raw value, not the ValueHelper normally returned by the tags. Also, you need to be prepared to handle None values. Your comparison becomes something like (NOT TESTED): #set pm2_5 =

Re: [weewx-development] WU wind speed and wind gust graph issue with rapidfire - would LOOP2 packet resolve it?

No. It's on the list! -tk On Wed, Aug 21, 2019 at 6:08 PM Praveen Chandrasekaran < praveen.c...@gmail.com> wrote: > Are the new parameters to WU (#435) also done? > > On Thu, 22 Aug 2019, 05:07 Thomas Keffer, wrote: > >> Yes, LOOP2 is now a first-class citizen. You can

Re: [weewx-development] WU wind speed and wind gust graph issue with rapidfire - would LOOP2 packet resolve it?

Yes, LOOP2 is now a first-class citizen. You can use it in lieu of LOOP1 packets, or alternate between them. But, I think this is something for more advanced users. You have to fiddle with the values in [StdWXCalculate] to make it work properly. But, it does get you THSW! -tk On Wed, Aug 21,

Re: [weewx-development] Re: Weather Link Live - Driver

If you're going to write a driver, it's worth reading the Customizing Guide on the subject . -tk On Mon, Jul 1, 2019 at 8:23 AM Tom wrote: > Hi Gary, > > Thanks for the reply! > > I see, so 'rain' is an archive field

Re: [weewx-development] ConfigObj question

Unfortunately, no. Without the validator, everything ConfigObj returns is a string. However, there are some useful utility functions in weeutil.weeutil: to_int(), to_float(), and to_bool(), which take care of possible 'None' values. They are sprinkled throughout WeeWX, wherever a conversion needs

Re: [weewx-development] Re: i'm willing to test...

If you cloned your repository from https://github.com/weewx/weewx, then these steps are extremely easy. Just # If you haven't already done it: git clone https://github.com/weewx/weewx.git # Then... git checkout development git pull That's it. No make involved. On Tue, May 7, 2019 at 10:29 PM

Re: [weewx-development] get converted value and units, inside example alarm.py

Preferred unit system? That's up to you! I'm assuming you want to send yourself a message when the alarm goes off. That message should use whatever unit system you prefer. On Wed, May 1, 2019 at 1:58 AM Graham Eddy wrote: > great! that fixed the conversion problem > > nearly there. is there

Re: [weewx-development] get converted value and units, inside example alarm.py

Sorry. It should be: t_vh = weewx.units.ValueHelper(t_vt, converter=weewx.units.StdUnitConverters[weewx.METRICWX]) -tk On Tue, Apr 30, 2019 at 1:18 AM Graham Eddy wrote: > i tried the above and i am missing something... > it gives an attribute error for a well-known unit. clues would be

Re: [weewx-development] get converted value and units, inside example alarm.py

Unfortunately, there's no simple way to make the tag machinery available outside the StdReport context --- for one thing, there is no skin configuration (skin.conf) available. It would probably be easier just to do the conversions yourself. Something like this (NOT TESTED): def

Re: [weewx-development] Windy website API under definition ?

Hartmut: make sure you use your API key, not your ID. The API key is a very long sequence of letters and numbers (perhaps 80 to 100 characters). Pat: The station ID is yet another number. Just set it to zero. It's there to distinguish between stations, in case you have more than one. On Sat, Apr

Re: [weewx-development] Windy website API under definition ?

Are you sure you are using the current version of windy.py? Version 0.3 does not post the url to the log. In any case, use the attached version. Set debug=2, then restart weewx. This version (v0.31) will not only post the url to the log, but also the JSON body. -tk On Sat, Apr 20, 2019 at 6:57

Re: [weewx-development] Windy website API under definition ?

Here's a better link: https://www.windy.com/station/pws-f0776a1a?45.671,-121.539,5 On Thu, Apr 18, 2019 at 6:40 AM Thomas Keffer wrote: > It's working for me: https://www.windy.com/station?45.687,-121.570,8 > > -tk > > On Wed, Apr 17, 2019 at 5:25 AM Hartmut Schweidler >

Re: [weewx-development] Windy website API under definition ?

It's working for me: https://www.windy.com/station?45.687,-121.570,8 -tk On Wed, Apr 17, 2019 at 5:25 AM Hartmut Schweidler wrote: > Hallo > > windy.py > > Apr 17 14:15:37 wetter OWFS[22140]: restx: Windy: Failed to publish record > 2019-04-17 14:15:00 CEST (103300): Failed upload after 3

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

The pastebin version looks reasonable. I don't have a problem with the dictionary mapping to an appropriate function, provided that the OS names have been standardized. Have they? Definitely needs to be tested. The easiest is to set up a bunch of VMs (or Docker boxes) on your development machine

Re: [weewx-development] Windy website API under definition ?

Looks like they just published their API, all of 10 hours ago! https://community.windy.com/topic/8168/report-you-weather-station-data-to-windy/2 On Mon, Apr 15, 2019 at 4:18 PM Wysiwyg wrote: > > Dear weewx developer community, > > I'm a playing a bit currently with "Belchertown" very nice

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

I agree: stacks and stacks of try / except statements can lead to indent hell. One way to cut that down is to use functions. Each function would try / except a set of related operating systems, and if none of them work, raise NotImplementedError. The main function would then just have to catch

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

> > Would it be better to just use something more generic like uptime(1) and > parse the output? > A PR is welcome. 

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

> > Overall, I would want to replace the try/except/try notion with a switch > on os type and helper functions for groups of systems that have common > behavior. That's perhaps a bias on my part not to use exceptions for > things that could avoid them, and partly because this seems to be >

Re: [weewx-development] Python 3 version and NoneType and int

The ".raw" suffix means you will get the actual value, which could be a float, or it can be Python 'None'. If you are going to do a comparison, you must check to see if the value might be None. Your template code should look something like this: #if $trend.extraTemp9.raw is None Unknown

Re: [weewx-development] Python 3 version and NoneType and int

As far as I can tell, trends do not use the less than ('<') operator. Do you know what expression is triggering the exception? What is the template indexOWFS.html.tmpl? On Sun, Apr 7, 2019 at 3:50 AM Hartmut Schweidler wrote: > Hallo > I use the WeewWx-Version 4 from the development since

Re: [weewx-development] Re: Python 3 version available for limited testing

Thanks, Luc Make sure you forward them on to the respective authors. On Wed, Apr 3, 2019 at 6:04 PM wrote: > Tom, > > Improved versions for meteotemplate.py, wcloud.py and weather365.py. > The should run on both Python 2 and Python 3. > > Luc >

Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)

You get a "duplicate key" error from the database, which is logged, but ignored. On Thu, Mar 28, 2019 at 7:32 PM Henry Denston wrote: > Tom, can you tell me what WeeWX will do in case it gets a package with the > same unix timestamp a package already had before? > As dateTime is a unique key

Re: [weewx-development] Database access from driver

This is a common problem. For example, on the Vantage, the transmitter battery status only appears in LOOP packets, not archive records. The solution is to let WeeWX accumulate the packets, then extract a value at the end of the archive interval. You can extract the average value (which is what

Re: [weewx-development] Re: Python 3 version available for limited testing

at 12:53 PM Thomas Keffer wrote: > I can't speak to the logic of the code, but it looks like it should work > under Python 2 and 3. A couple things to think about: > >1. You cannot count on the user having the shim 'six', although it is >becoming increasingly comm

Re: [weewx-development] Re: Python 3 version available for limited testing

I can't speak to the logic of the code, but it looks like it should work under Python 2 and 3. A couple things to think about: 1. You cannot count on the user having the shim 'six', although it is becoming increasingly common. Many python installations include it by default. In any case,

Re: [weewx-development] Re: Python 3 version available for limited testing

Luc, You are very close to having a code base that will run under both Python 2 and 3. Suggestions: 1. Put this at the top to cover your use of multiple arguments to "print": from __future__ import print_function 2. For a queue, do this: try: # Python 2 from Queue import Queue except

Re: [weewx-development] Database access from driver

If you implement the method genArchiveRecords() there should be no reason to do this. It will pass in as its only argument the last timestamp in the database. So, do your retrieval since that timestamp. It should be a generator function, yielding records. -tk On Sun, Mar 24, 2019 at 8:21 AM

Re: [weewx-development] Re: windGust is always an even number ?

I have no idea. Have you tried a SELECT statement on your database to confirm? -tk On Fri, Mar 22, 2019 at 10:05 AM Pat wrote: > I should clarify my question. The windGust is always a *whole *number, > even when windSpeed in the loop is (usually) not. > > On Friday, March 22, 2019 at 12:36:19

Re: [weewx-development] Developing a WeeWX-Driver for custom weather station hardware (adding custom sensors)

That's right. On Thu, Mar 21, 2019 at 8:55 PM Henry Denston wrote: > Thank you for the clarification tom. > So I assume there are not going to be more tables added (e.g. for week, > month etc) but only the daily hi/lows, right? > > Regards, henry. > > On Friday, March 22, 2019 at 12:45:41 AM

Re: [weewx-development] windRun unit label is in miles only

You can. In fact, if you take a look at Seasons, that's basically what's been done. However, it will only work with V3.9, not older versions. -tk On Tue, Mar 12, 2019 at 5:36 PM Pat wrote: > I knew it was a lowercase R, not sure why I decided to camelCase it here. > > Thanks for the update and

Re: [weewx-development] windRun unit label is in miles only

Oops. That was a typo. I mean 'km' On Tue, Mar 12, 2019 at 5:44 PM Pat wrote: > Also Tom, while testing, looks like the valid input for group_distance is > either "mile" or "km" (no _per_hour). > > > On Tuesday, March 12, 2019 at 8:33:26 PM UTC-4, Tom Keffer wrote: >> >> The type 'windrun'

Re: [weewx-development] windRun unit label is in miles only

The type 'windrun' (note the lower-case 'r') is part of group_distance, which was inadvertently left out of the set of groups that get switched when the user selects metric or US (it doesn't appear in any of the skins that are part of WeeWX). It is easily added. Go into weewx.conf, section

Re: [weewx-development] Re: Python 3 version available for limited testing

Yes, this is a limitation in the way database bindings are presently implemented. It is very hard for a search list extension (in this case, $alltime) to use a custom binding. Thank you for reminding me. Version 4 would be a good time to introduce these kinds of changes, as they may break

Re: [weewx-development] Re: Python 3 version available for limited testing

Thanks again! Fixed in commit 6c24156 Do a pull, and try again. On Sat, Mar 2, 2019 at 11:18 AM Hartmut Schweidler wrote: > I uploaded the "public_html" via fileZilla for testing > > the site on

Re: [weewx-development] Re: Python 3 version available for limited testing

Thanks, Hartmut! I think the problem is that the file that is to be FTP'd, was being opened in text mode instead of binary. So, it was trying to decode it into Unicode. Fixed in commit 5167069 Do a pull on the

[weewx-development] Python 3 version available for limited testing

It's alive, and it works reliably with the Vantage driver! But it's untested for any other drivers. I would greatly appreciate it if others took it for a spin with other drivers! To install, it's probably best to just run out of a git repository, with the python3 branch, but using your existing

<    1   2   3   >