[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Thanks for the info.

James

On Friday, February 18, 2022 at 10:24:21 PM UTC gjr80 wrote:

> No problems James. 
>
> Regards the services, think of the [[Services]] stanza as a matrix. When 
> an event occurs (for example the arrival of a new archive record) WeeWX 
> works it way down each 'row' (ie each _services option) in turn 
> checking each 'column' (ie each service defined in that row) to see if that 
> service was bound to the event in question. If it is bound WeeWX executes 
> the designated code (method) for that service, if it's not bound WeeWX 
> moves on to the next 'column'/service. The services are loosely grouped by 
> type, but there is really no great difference between service types. Order 
> matters, typically services towards the top of the list (eg data) will be 
> doing things to the incoming data to maybe add observations, eg you may 
> have a service that reads air quality data from a separate sensor suite and 
> adds it to loop packets and archive records (such a service would likely be 
> bound to the new archive record and new loop packet events). You would not 
> put such a service after StdArchive as the data would not be saved to the 
> archive. Services that process the incoming data and perhaps change the 
> archive record (eg StdWxCalculate) need to be 'placed' after all of the 
> incoming data has been assembled but before StdArchive writes the archive 
> record to database.
>
> In your case some careful placement of your service in the processing 
> chain has solved the problem.
>
> Gary
>
> On Friday, 18 February 2022 at 19:42:43 UTC+10 James Taylor wrote:
>
>> Sorry Gary
>>
>> Yes I was also annoyed when I caught the extension and remembered why it 
>> was there :-(   I did learn a lot more about the code setup.  I had been 
>> running the debug at 2 and still missed it so therefore renamed it to 
>> windDir so it matches the same case at least!
>>
>> I'm still trying to fully understand the 'services' implementation, but 
>> yes I've moved it from data_services to the end of process_services, and 
>> also before weewx.engine.StdArchive and in both cases it continued to 
>> operate as expected.
>>
>> I will update Belchertown users in case they are using Pat's service.
>>
>> Thanks again and sorry for the long winded way of getting there.
>>
>> James
>>
>> On Friday, February 18, 2022 at 1:56:39 AM UTC gjr80 wrote:
>>
>>> So if I understand your post correctly you are running Pat's service to 
>>> delete windDir from archive records? If so that sort of info would have 
>>> been nice to know from the outset; that is why we ask for a startup log 
>>> with debug=1 - it gives us key WeeWX config info so we know what 
>>> services are being run and what aren't.
>>>
>>> Again if you are running Pat's service then the solution should be 
>>> fairly straightforward; instead of running the service as a data service, 
>>> run it as a process service but list it after StdWxCalculate. This way 
>>> StdWxCalculate can do whatever to the archive record and then Pat's 
>>> service will come along and delete windDir. When StdArchive steps in it 
>>> will extract windDir from the accumulator as before (assuming windDir 
>>> is in loop packets) and add it to the archive record before it is saved to 
>>> database. Making Pat's service an archive service would probably work as 
>>> well, as long as it was listed in archive_services in weewx.conf before 
>>> StdArchive.
>>>
>>> Gary
>>>
>>> On Thursday, 17 February 2022 at 23:49:56 UTC+10 James Taylor wrote:
>>>
 Hello

 So this was broken by commit ec958a0 (
 https://github.com/weewx/weewx/commit/ec958a0658612ef3bce90ab5c6e825ef0d329e8e
 ).

 To give the history, to allow Belchertown to output / graph rxCheckPercent 
 as discussed here 
 https://www.mail-archive.com/weewx...@googlegroups.com/msg21816.html 
 , 
 it meant we delete windDir from the Vantage archive record which means we 
 then process the loop packets as an accumulator

 I'm guessing this will need the brains / knowledge of Tom to comment???

 James
 On Wednesday, February 16, 2022 at 10:55:01 PM UTC James Taylor wrote:

> Tonight's debug
>
> So I've detected that I'm not getting windDir on the archive record 
> from the Vantage Pro 2 on the records coming every 5 mins, compared to 
> any 
> archive records received after a restart, so possibly a hardware issue.
>
> PRESENT -
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Getting 
> archive packets since 2022-02-16 21:25:00 GMT (1645046700)
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Gentle 
> wake up of console successful
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Retrieving 
> 1 page(s); starting index= 0
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.engine: REC:  

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Aslak Vaa]

Thank you for the clarification.

On Tuesday, February 22, 2022 at 7:43:22 PM UTC+1 tke...@gmail.com wrote:

> The accumulators for windDir and windGustDir are useless. If the wind 
> blows at 359° for an hour, then 1° for an hour, the windDir accumulator 
> would return 180°. They are there only because it's easiest to just create 
> an accumulator for everything.
>
> Same with the daily summaries for windDir and windGustDir: worthless.
>
> What you want is held in the accumulator for the vector quantity 'wind', 
> where wind is treated as a true vector. It includes attributes max and 
> max_dir, which holds the max wind speed seen and its direction, 
> respectively. 
>
> The equivalent in the database for daily summaries is held in 
> archive_day_wind. There, you can calculate the average wind (from wsum and 
> sumtime), average vector wind direction (from xsum and ysum), max gust 
> (from max), as well as the direction of the max gust (from max_dir). This 
> is all taken care of for you if you use the tag $wind.
>
> Hope I got a little closer to answering your questions!
>
> On Tue, Feb 22, 2022 at 7:52 AM Aslak Vaa  wrote:
>
>> Sorry, that was not my intended question.
>> My issue is that I see wind speed and direction as a pair of values for 
>> any given time. When we speak of max wind, I am interested of the speed of 
>> wind and its direction at that time. The speed is the main issue, and 
>> direction is an attribute to the speed.
>> This applies both to windSpeed and windGust.
>> This might be solved removing the accumulation tables for windDir and 
>> windGustDir, and adding directions to accumulation tables for windSpeed and 
>> windGust both for min and max values of wind speed.
>> I have not looked into the possibility that there may be other groups of 
>> information that may have a similar need of handling.
>> I see that this may break the accumulation scheme.
>> So, yes, for the moment I think you are correct in seeing the case as a 
>> feature.
>>
>>
>>
>> On Tuesday, February 22, 2022 at 3:04:51 PM UTC+1 tke...@gmail.com wrote:
>>
>>> LOL! Well, I guess you could say it's a feature.
>>>
>>> max in archive_day_windSpeed is the maximum value seen for 'windSpeed'.
>>> max in archive_day_windGust is the maximum value seen for 'windGust'.
>>>
>>> They are not necessarily the same because archived windSpeed is 
>>> typically the average wind seen over an archive interval. By contrast, 
>>> archived windGust is the max wind seen over an archive interval.
>>>
>>> Hope that's what you're looking for.
>>>
>>> On Tue, Feb 22, 2022 at 4:55 AM Aslak Vaa  wrote:
>>>
 The enclosed file was not correct in my last reply.
 Please see this new file.

 Best Regards, Aslak

 On Tuesday, February 22, 2022 at 1:47:36 PM UTC+1 Aslak Vaa wrote:

> I have installed your last update, and I will keep an eye on the 
> results for the next days. Thank you for following up the issue.
>
> However, I performed queries from the accumulator tables for 
> windSpeed, windDir, windGust and windGustDir. The mintime/maxtime for 
> wind 
> and direction are unequal both for windSpeed/windDir and 
> windGust/windGustDir min/max values.
> I expected that the min/max values of windDir/windGustDir should be 
> the values at the same mintime/maxtime as the corresponding min/max for 
> windSpeed/windGust  values. This is not the case.
> Is this an error or a feature?
> Please find queries and results in enclosed file.
>
> Best Regards, Aslak
>
> On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com 
> wrote:
>
>> Upon reflection, I really didn't like the solution I posted earlier. 
>> The reality is that for stations that do not supply windGustDir, such as 
>> the Fine Offset stations, weewx was calculating a substitute just fine: 
>> the 
>> vector average of the wind over an archive period was being extracted 
>> from 
>> the accumulators. The problem is that because of the peculiarities of 
>> how 
>> WXXTypes was set up, it was forcing windGustDir to None if windGustDir 
>> was 
>> missing, which caused the calculated value not to get substituted. Then 
>> I 
>> supplied a band-aid over this by substituting windDir instead.
>>
>> A mess.
>>
>> With commit 244a7f8 
>> ,
>>  
>> I've changed this to do nothing in WXXTypes if windGustDir is missing. 
>> This 
>> causes a value to be successfully extracted from the accumulators.
>>
>> A long-winded way to say that I think the new solution is a better, 
>> more accurate one.
>>
>> If you're comfortable using git, I'd appreciate it if one of you FO 
>> owners could give it a try.
>>
>> -tk
>>
>>
>>
>> On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com <

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Tom Keffer]

The accumulators for windDir and windGustDir are useless. If the wind blows
at 359° for an hour, then 1° for an hour, the windDir accumulator would
return 180°. They are there only because it's easiest to just create an
accumulator for everything.

Same with the daily summaries for windDir and windGustDir: worthless.

What you want is held in the accumulator for the vector quantity 'wind',
where wind is treated as a true vector. It includes attributes max and
max_dir, which holds the max wind speed seen and its direction,
respectively.

The equivalent in the database for daily summaries is held in
archive_day_wind. There, you can calculate the average wind (from wsum and
sumtime), average vector wind direction (from xsum and ysum), max gust
(from max), as well as the direction of the max gust (from max_dir). This
is all taken care of for you if you use the tag $wind.

Hope I got a little closer to answering your questions!

On Tue, Feb 22, 2022 at 7:52 AM Aslak Vaa  wrote:

> Sorry, that was not my intended question.
> My issue is that I see wind speed and direction as a pair of values for
> any given time. When we speak of max wind, I am interested of the speed of
> wind and its direction at that time. The speed is the main issue, and
> direction is an attribute to the speed.
> This applies both to windSpeed and windGust.
> This might be solved removing the accumulation tables for windDir and
> windGustDir, and adding directions to accumulation tables for windSpeed and
> windGust both for min and max values of wind speed.
> I have not looked into the possibility that there may be other groups of
> information that may have a similar need of handling.
> I see that this may break the accumulation scheme.
> So, yes, for the moment I think you are correct in seeing the case as a
> feature.
>
>
>
> On Tuesday, February 22, 2022 at 3:04:51 PM UTC+1 tke...@gmail.com wrote:
>
>> LOL! Well, I guess you could say it's a feature.
>>
>> max in archive_day_windSpeed is the maximum value seen for 'windSpeed'.
>> max in archive_day_windGust is the maximum value seen for 'windGust'.
>>
>> They are not necessarily the same because archived windSpeed is typically
>> the average wind seen over an archive interval. By contrast, archived
>> windGust is the max wind seen over an archive interval.
>>
>> Hope that's what you're looking for.
>>
>> On Tue, Feb 22, 2022 at 4:55 AM Aslak Vaa  wrote:
>>
>>> The enclosed file was not correct in my last reply.
>>> Please see this new file.
>>>
>>> Best Regards, Aslak
>>>
>>> On Tuesday, February 22, 2022 at 1:47:36 PM UTC+1 Aslak Vaa wrote:
>>>
 I have installed your last update, and I will keep an eye on the
 results for the next days. Thank you for following up the issue.

 However, I performed queries from the accumulator tables for windSpeed,
 windDir, windGust and windGustDir. The mintime/maxtime for wind and
 direction are unequal both for windSpeed/windDir and windGust/windGustDir
 min/max values.
 I expected that the min/max values of windDir/windGustDir should be the
 values at the same mintime/maxtime as the corresponding min/max for
 windSpeed/windGust  values. This is not the case.
 Is this an error or a feature?
 Please find queries and results in enclosed file.

 Best Regards, Aslak

 On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com
 wrote:

> Upon reflection, I really didn't like the solution I posted earlier.
> The reality is that for stations that do not supply windGustDir, such as
> the Fine Offset stations, weewx was calculating a substitute just fine: 
> the
> vector average of the wind over an archive period was being extracted from
> the accumulators. The problem is that because of the peculiarities of how
> WXXTypes was set up, it was forcing windGustDir to None if windGustDir was
> missing, which caused the calculated value not to get substituted. Then I
> supplied a band-aid over this by substituting windDir instead.
>
> A mess.
>
> With commit 244a7f8
> ,
> I've changed this to do nothing in WXXTypes if windGustDir is missing. 
> This
> causes a value to be successfully extracted from the accumulators.
>
> A long-winded way to say that I think the new solution is a better,
> more accurate one.
>
> If you're comfortable using git, I'd appreciate it if one of you FO
> owners could give it a try.
>
> -tk
>
>
>
> On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com 
> wrote:
>
>> Checked this morning and pleased to say Max Wind direction is now
>> reporting and updating in the Day tab of the Statistics section. Still 
>> N/A
>> in Week but I'm guessing it will update in due course.
>> Just out of interest I've noticed in the Statistics section the Year

Re: [weewx-user] Upgrading Weewx - Vlink Weatherlink

['Sofia_' via weewx-user]

Thank you very much, and thanks also for the weewx project that is great. 
Have a nice day, 

Sofia

Il giorno martedì 22 febbraio 2022 alle 17:30:41 UTC+1 tke...@gmail.com ha 
scritto:

> I am not aware of a Python 3 version of that extension. Matthew is 
> unavailable until the end of the month. I will try and take a look at it 
> sometime this week.
>
> On Tue, Feb 22, 2022 at 8:15 AM 'Sofia_' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Thank you for your promptly reply.
>>
>> I'm using the WLink driver 0.14 (wlink.py 1783 2018-01-29 by mwall), but 
>> mine is for Python 2.7 (I see some modules in the code, such as the urllib2 
>> that is for Python2).
>> The stations are Vantage Vue Pro equipped with the WeatherLinkIp driver.
>>  
>> I read about the WLL Driver (weatherlinklive-driver-weewx) but i don't 
>> have the  WeatherLinkLive module in my stations, so I don't know if it 
>> could be a good choice for me.
>>
>> Is there a version of the WLink driver compliant with Python3? It's very 
>> smart, because it requires only few info for the connection (Mac address of 
>> the station and Weatherlink pwd).
>>
>> I tried to do a self translation of the wlink.py from Python2 to 3, but I 
>> did a mess because I'm not a programmer.
>>
>>
>> Sofia
>>
>>
>>
>>
>> Il giorno martedì 22 febbraio 2022 alle 16:48:15 UTC+1 tke...@gmail.com 
>> ha scritto:
>>
>>> That's quite the setup you have there!
>>>
>>> There are several wlink drivers. Which one are you using?
>>>
>>> On Tue, Feb 22, 2022 at 7:33 AM 'Sofia_' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Dears,

 Currently, i'm working on a Debian server where are running about 7 
 instances of weewx (7 Davis Vantage meteo stations, six of them are 
 located 
 in Italy and the last one in Costa Rica).
 I use as a driver the wlink - weewx driver that gets data from the 
 weatherlink web site. 
 Now, I would upgrade my old weewx installation (Python 2.7) with a new 
 weewx version (with Python 3.x).
 Is still possible to use the vlink driver with Python 3? 
 I found the "0.14" as last version.

 Thank you in advance,

 Sofia 

 -- 
 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 weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/5d9e0aa8-fe84-44ff-a3e1-56fde174f3a1n%40googlegroups.com
  
 
 .

>>> -- 
>> 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 weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/068106af-1b1a-4346-a33c-af470fe7e2adn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/724f8890-f4f7-4f99-87a3-4b49e0d8b11an%40googlegroups.com.

Re: [weewx-user] Upgrading Weewx - Vlink Weatherlink

[Tom Keffer]

I am not aware of a Python 3 version of that extension. Matthew is
unavailable until the end of the month. I will try and take a look at it
sometime this week.

On Tue, Feb 22, 2022 at 8:15 AM 'Sofia_' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Thank you for your promptly reply.
>
> I'm using the WLink driver 0.14 (wlink.py 1783 2018-01-29 by mwall), but
> mine is for Python 2.7 (I see some modules in the code, such as the urllib2
> that is for Python2).
> The stations are Vantage Vue Pro equipped with the WeatherLinkIp driver.
>
> I read about the WLL Driver (weatherlinklive-driver-weewx) but i don't
> have the  WeatherLinkLive module in my stations, so I don't know if it
> could be a good choice for me.
>
> Is there a version of the WLink driver compliant with Python3? It's very
> smart, because it requires only few info for the connection (Mac address of
> the station and Weatherlink pwd).
>
> I tried to do a self translation of the wlink.py from Python2 to 3, but I
> did a mess because I'm not a programmer.
>
>
> Sofia
>
>
>
>
> Il giorno martedì 22 febbraio 2022 alle 16:48:15 UTC+1 tke...@gmail.com
> ha scritto:
>
>> That's quite the setup you have there!
>>
>> There are several wlink drivers. Which one are you using?
>>
>> On Tue, Feb 22, 2022 at 7:33 AM 'Sofia_' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Dears,
>>>
>>> Currently, i'm working on a Debian server where are running about 7
>>> instances of weewx (7 Davis Vantage meteo stations, six of them are located
>>> in Italy and the last one in Costa Rica).
>>> I use as a driver the wlink - weewx driver that gets data from the
>>> weatherlink web site.
>>> Now, I would upgrade my old weewx installation (Python 2.7) with a new
>>> weewx version (with Python 3.x).
>>> Is still possible to use the vlink driver with Python 3?
>>> I found the "0.14" as last version.
>>>
>>> Thank you in advance,
>>>
>>> Sofia
>>>
>>> --
>>> 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 weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/5d9e0aa8-fe84-44ff-a3e1-56fde174f3a1n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/068106af-1b1a-4346-a33c-af470fe7e2adn%40googlegroups.com
> 
> .
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEAwPeDkhng2%2BxkwTe-56e5eU6Gmx5Ss%3DWYLqq9MXXrrgQ%40mail.gmail.com.

Re: [weewx-user] Upgrading Weewx - Vlink Weatherlink

['Sofia_' via weewx-user]

Thank you for your promptly reply.

I'm using the WLink driver 0.14 (wlink.py 1783 2018-01-29 by mwall), but 
mine is for Python 2.7 (I see some modules in the code, such as the urllib2 
that is for Python2).
The stations are Vantage Vue Pro equipped with the WeatherLinkIp driver.
 
I read about the WLL Driver (weatherlinklive-driver-weewx) but i don't have 
the  WeatherLinkLive module in my stations, so I don't know if it could be 
a good choice for me.

Is there a version of the WLink driver compliant with Python3? It's very 
smart, because it requires only few info for the connection (Mac address of 
the station and Weatherlink pwd).

I tried to do a self translation of the wlink.py from Python2 to 3, but I 
did a mess because I'm not a programmer.


Sofia




Il giorno martedì 22 febbraio 2022 alle 16:48:15 UTC+1 tke...@gmail.com ha 
scritto:

> That's quite the setup you have there!
>
> There are several wlink drivers. Which one are you using?
>
> On Tue, Feb 22, 2022 at 7:33 AM 'Sofia_' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Dears,
>>
>> Currently, i'm working on a Debian server where are running about 7 
>> instances of weewx (7 Davis Vantage meteo stations, six of them are located 
>> in Italy and the last one in Costa Rica).
>> I use as a driver the wlink - weewx driver that gets data from the 
>> weatherlink web site. 
>> Now, I would upgrade my old weewx installation (Python 2.7) with a new 
>> weewx version (with Python 3.x).
>> Is still possible to use the vlink driver with Python 3? 
>> I found the "0.14" as last version.
>>
>> Thank you in advance,
>>
>> Sofia 
>>
>> -- 
>> 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 weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/5d9e0aa8-fe84-44ff-a3e1-56fde174f3a1n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/068106af-1b1a-4346-a33c-af470fe7e2adn%40googlegroups.com.

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Aslak Vaa]

Sorry, that was not my intended question.
My issue is that I see wind speed and direction as a pair of values for any 
given time. When we speak of max wind, I am interested of the speed of wind 
and its direction at that time. The speed is the main issue, and direction 
is an attribute to the speed.
This applies both to windSpeed and windGust.
This might be solved removing the accumulation tables for windDir and 
windGustDir, and adding directions to accumulation tables for windSpeed and 
windGust both for min and max values of wind speed.
I have not looked into the possibility that there may be other groups of 
information that may have a similar need of handling.
I see that this may break the accumulation scheme.
So, yes, for the moment I think you are correct in seeing the case as a 
feature.



On Tuesday, February 22, 2022 at 3:04:51 PM UTC+1 tke...@gmail.com wrote:

> LOL! Well, I guess you could say it's a feature.
>
> max in archive_day_windSpeed is the maximum value seen for 'windSpeed'.
> max in archive_day_windGust is the maximum value seen for 'windGust'.
>
> They are not necessarily the same because archived windSpeed is typically 
> the average wind seen over an archive interval. By contrast, archived 
> windGust is the max wind seen over an archive interval.
>
> Hope that's what you're looking for.
>
> On Tue, Feb 22, 2022 at 4:55 AM Aslak Vaa  wrote:
>
>> The enclosed file was not correct in my last reply.
>> Please see this new file.
>>
>> Best Regards, Aslak
>>
>> On Tuesday, February 22, 2022 at 1:47:36 PM UTC+1 Aslak Vaa wrote:
>>
>>> I have installed your last update, and I will keep an eye on the results 
>>> for the next days. Thank you for following up the issue.
>>>
>>> However, I performed queries from the accumulator tables for windSpeed, 
>>> windDir, windGust and windGustDir. The mintime/maxtime for wind and 
>>> direction are unequal both for windSpeed/windDir and windGust/windGustDir 
>>> min/max values.
>>> I expected that the min/max values of windDir/windGustDir should be the 
>>> values at the same mintime/maxtime as the corresponding min/max for 
>>> windSpeed/windGust  values. This is not the case.
>>> Is this an error or a feature?
>>> Please find queries and results in enclosed file.
>>>
>>> Best Regards, Aslak
>>>
>>> On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com 
>>> wrote:
>>>
 Upon reflection, I really didn't like the solution I posted earlier. 
 The reality is that for stations that do not supply windGustDir, such as 
 the Fine Offset stations, weewx was calculating a substitute just fine: 
 the 
 vector average of the wind over an archive period was being extracted from 
 the accumulators. The problem is that because of the peculiarities of how 
 WXXTypes was set up, it was forcing windGustDir to None if windGustDir was 
 missing, which caused the calculated value not to get substituted. Then I 
 supplied a band-aid over this by substituting windDir instead.

 A mess.

 With commit 244a7f8 
 ,
  
 I've changed this to do nothing in WXXTypes if windGustDir is missing. 
 This 
 causes a value to be successfully extracted from the accumulators.

 A long-winded way to say that I think the new solution is a better, 
 more accurate one.

 If you're comfortable using git, I'd appreciate it if one of you FO 
 owners could give it a try.

 -tk



 On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com  
 wrote:

> Checked this morning and pleased to say Max Wind direction is now 
> reporting and updating in the Day tab of the Statistics section. Still 
> N/A 
> in Week but I'm guessing it will update in due course.
> Just out of interest I've noticed in the Statistics section the Year 
> tab is blue and if you click on it you get the option of Year or Rain 
> Year. 
> What actually is the difference between these two? In my case the values 
> reported are identical.
> Paul
>
> On Sunday, 13 February 2022 at 20:01:25 UTC remy.l...@gmail.com wrote:
>
>> Yes, it’s the good python file, same as me  (if standard 
>> installation...)
>> The Tom’s update/patch solves perfectly the problem and also min/max 
>> windGustDir data base.
>> Try stop and start weewx (logicaly same thing as restart... !?)
>> Try to look for all wxxtype.py on your system to see if there is 
>> another file ? Logicaly no...
>>
>>
>> Le dimanche 13 février 2022 à 20:23:07 UTC+1, paul...@gmail.com a 
>> écrit :
>>
>>> Hi Remy
>>> Yes I did sudo /etc/init.d/weewx restart. Just in case I've done it 
>>> again but no change.
>>> Can I just check I swapped the correct wxxtypes.py file. I swapped 
>>> the one in /usr/share/weewx/weewx
>>> Paul
>>>
>>> On 

Re: [weewx-user] Upgrading Weewx - Vlink Weatherlink

[Tom Keffer]

That's quite the setup you have there!

There are several wlink drivers. Which one are you using?

On Tue, Feb 22, 2022 at 7:33 AM 'Sofia_' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Dears,
>
> Currently, i'm working on a Debian server where are running about 7
> instances of weewx (7 Davis Vantage meteo stations, six of them are located
> in Italy and the last one in Costa Rica).
> I use as a driver the wlink - weewx driver that gets data from the
> weatherlink web site.
> Now, I would upgrade my old weewx installation (Python 2.7) with a new
> weewx version (with Python 3.x).
> Is still possible to use the vlink driver with Python 3?
> I found the "0.14" as last version.
>
> Thank you in advance,
>
> Sofia
>
> --
> 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 weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/5d9e0aa8-fe84-44ff-a3e1-56fde174f3a1n%40googlegroups.com
> 
> .
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zECP_LSrLV5UG-7JmOgtOha1EVFOoC4XUJ-zVcJ_a3%2BnEQ%40mail.gmail.com.

[weewx-user] Upgrading Weewx - Vlink Weatherlink

['Sofia_' via weewx-user]

Dears,

Currently, i'm working on a Debian server where are running about 7 
instances of weewx (7 Davis Vantage meteo stations, six of them are located 
in Italy and the last one in Costa Rica).
I use as a driver the wlink - weewx driver that gets data from the 
weatherlink web site. 
Now, I would upgrade my old weewx installation (Python 2.7) with a new 
weewx version (with Python 3.x).
Is still possible to use the vlink driver with Python 3? 
I found the "0.14" as last version.

Thank you in advance,

Sofia

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5d9e0aa8-fe84-44ff-a3e1-56fde174f3a1n%40googlegroups.com.

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Tom Keffer]

LOL! Well, I guess you could say it's a feature.

max in archive_day_windSpeed is the maximum value seen for 'windSpeed'.
max in archive_day_windGust is the maximum value seen for 'windGust'.

They are not necessarily the same because archived windSpeed is typically
the average wind seen over an archive interval. By contrast, archived
windGust is the max wind seen over an archive interval.

Hope that's what you're looking for.

On Tue, Feb 22, 2022 at 4:55 AM Aslak Vaa  wrote:

> The enclosed file was not correct in my last reply.
> Please see this new file.
>
> Best Regards, Aslak
>
> On Tuesday, February 22, 2022 at 1:47:36 PM UTC+1 Aslak Vaa wrote:
>
>> I have installed your last update, and I will keep an eye on the results
>> for the next days. Thank you for following up the issue.
>>
>> However, I performed queries from the accumulator tables for windSpeed,
>> windDir, windGust and windGustDir. The mintime/maxtime for wind and
>> direction are unequal both for windSpeed/windDir and windGust/windGustDir
>> min/max values.
>> I expected that the min/max values of windDir/windGustDir should be the
>> values at the same mintime/maxtime as the corresponding min/max for
>> windSpeed/windGust  values. This is not the case.
>> Is this an error or a feature?
>> Please find queries and results in enclosed file.
>>
>> Best Regards, Aslak
>>
>> On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com
>> wrote:
>>
>>> Upon reflection, I really didn't like the solution I posted earlier. The
>>> reality is that for stations that do not supply windGustDir, such as the
>>> Fine Offset stations, weewx was calculating a substitute just fine: the
>>> vector average of the wind over an archive period was being extracted from
>>> the accumulators. The problem is that because of the peculiarities of how
>>> WXXTypes was set up, it was forcing windGustDir to None if windGustDir was
>>> missing, which caused the calculated value not to get substituted. Then I
>>> supplied a band-aid over this by substituting windDir instead.
>>>
>>> A mess.
>>>
>>> With commit 244a7f8
>>> ,
>>> I've changed this to do nothing in WXXTypes if windGustDir is missing. This
>>> causes a value to be successfully extracted from the accumulators.
>>>
>>> A long-winded way to say that I think the new solution is a better, more
>>> accurate one.
>>>
>>> If you're comfortable using git, I'd appreciate it if one of you FO
>>> owners could give it a try.
>>>
>>> -tk
>>>
>>>
>>>
>>> On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com 
>>> wrote:
>>>
 Checked this morning and pleased to say Max Wind direction is now
 reporting and updating in the Day tab of the Statistics section. Still N/A
 in Week but I'm guessing it will update in due course.
 Just out of interest I've noticed in the Statistics section the Year
 tab is blue and if you click on it you get the option of Year or Rain Year.
 What actually is the difference between these two? In my case the values
 reported are identical.
 Paul

 On Sunday, 13 February 2022 at 20:01:25 UTC remy.l...@gmail.com wrote:

> Yes, it’s the good python file, same as me  (if standard
> installation...)
> The Tom’s update/patch solves perfectly the problem and also min/max
> windGustDir data base.
> Try stop and start weewx (logicaly same thing as restart... !?)
> Try to look for all wxxtype.py on your system to see if there is
> another file ? Logicaly no...
>
>
> Le dimanche 13 février 2022 à 20:23:07 UTC+1, paul...@gmail.com a
> écrit :
>
>> Hi Remy
>> Yes I did sudo /etc/init.d/weewx restart. Just in case I've done it
>> again but no change.
>> Can I just check I swapped the correct wxxtypes.py file. I swapped
>> the one in /usr/share/weewx/weewx
>> Paul
>>
>> On Sunday, 13 February 2022 at 18:08:44 UTC remy.l...@gmail.com
>> wrote:
>>
>>> Hi Paul.
>>> Have you triedto stop weewx and restart it ?
>>> You must do that if you modify python file.
>>> Cordialy
>>>
>>>
>>> Le dimanche 13 février 2022 à 18:32:38 UTC+1, paul...@gmail.com a
>>> écrit :
>>>
 I don't report wind gust values/direction in the Current Conditions
 section of my Seasons skin (version 4.6.2) but in the Statistics
 (previously High/Low) section I've always had a Max Wind entry with 
 both
 speed and direction reported. Since 4.6.2 the direction is reported as 
 N/A
 so I've followed this thread and replaced the wxxtypes.py file with 
 the new
 one from Tom but it doesn't seem to have made any difference to my Max 
 Wind
 entry. If you look at the Statistics report below it still shows N/A 
 for
 Max Wind degrees for Day and Week but for Month and Year (presumably 
 data
 from 

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Aslak Vaa]

The enclosed file was not correct in my last reply.
Please see this new file.

Best Regards, Aslak

On Tuesday, February 22, 2022 at 1:47:36 PM UTC+1 Aslak Vaa wrote:

> I have installed your last update, and I will keep an eye on the results 
> for the next days. Thank you for following up the issue.
>
> However, I performed queries from the accumulator tables for windSpeed, 
> windDir, windGust and windGustDir. The mintime/maxtime for wind and 
> direction are unequal both for windSpeed/windDir and windGust/windGustDir 
> min/max values.
> I expected that the min/max values of windDir/windGustDir should be the 
> values at the same mintime/maxtime as the corresponding min/max for 
> windSpeed/windGust  values. This is not the case.
> Is this an error or a feature?
> Please find queries and results in enclosed file.
>
> Best Regards, Aslak
>
> On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com wrote:
>
>> Upon reflection, I really didn't like the solution I posted earlier. The 
>> reality is that for stations that do not supply windGustDir, such as the 
>> Fine Offset stations, weewx was calculating a substitute just fine: the 
>> vector average of the wind over an archive period was being extracted from 
>> the accumulators. The problem is that because of the peculiarities of how 
>> WXXTypes was set up, it was forcing windGustDir to None if windGustDir was 
>> missing, which caused the calculated value not to get substituted. Then I 
>> supplied a band-aid over this by substituting windDir instead.
>>
>> A mess.
>>
>> With commit 244a7f8 
>> ,
>>  
>> I've changed this to do nothing in WXXTypes if windGustDir is missing. This 
>> causes a value to be successfully extracted from the accumulators.
>>
>> A long-winded way to say that I think the new solution is a better, more 
>> accurate one.
>>
>> If you're comfortable using git, I'd appreciate it if one of you FO 
>> owners could give it a try.
>>
>> -tk
>>
>>
>>
>> On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com  
>> wrote:
>>
>>> Checked this morning and pleased to say Max Wind direction is now 
>>> reporting and updating in the Day tab of the Statistics section. Still N/A 
>>> in Week but I'm guessing it will update in due course.
>>> Just out of interest I've noticed in the Statistics section the Year tab 
>>> is blue and if you click on it you get the option of Year or Rain Year. 
>>> What actually is the difference between these two? In my case the values 
>>> reported are identical.
>>> Paul
>>>
>>> On Sunday, 13 February 2022 at 20:01:25 UTC remy.l...@gmail.com wrote:
>>>
 Yes, it’s the good python file, same as me  (if standard 
 installation...)
 The Tom’s update/patch solves perfectly the problem and also min/max 
 windGustDir data base.
 Try stop and start weewx (logicaly same thing as restart... !?)
 Try to look for all wxxtype.py on your system to see if there is 
 another file ? Logicaly no...


 Le dimanche 13 février 2022 à 20:23:07 UTC+1, paul...@gmail.com a 
 écrit :

> Hi Remy
> Yes I did sudo /etc/init.d/weewx restart. Just in case I've done it 
> again but no change.
> Can I just check I swapped the correct wxxtypes.py file. I swapped the 
> one in /usr/share/weewx/weewx
> Paul
>
> On Sunday, 13 February 2022 at 18:08:44 UTC remy.l...@gmail.com wrote:
>
>> Hi Paul.
>> Have you triedto stop weewx and restart it ?
>> You must do that if you modify python file.
>> Cordialy 
>>
>>
>> Le dimanche 13 février 2022 à 18:32:38 UTC+1, paul...@gmail.com a 
>> écrit :
>>
>>> I don't report wind gust values/direction in the Current Conditions 
>>> section of my Seasons skin (version 4.6.2) but in the Statistics 
>>> (previously High/Low) section I've always had a Max Wind entry with 
>>> both 
>>> speed and direction reported. Since 4.6.2 the direction is reported as 
>>> N/A 
>>> so I've followed this thread and replaced the wxxtypes.py file with the 
>>> new 
>>> one from Tom but it doesn't seem to have made any difference to my Max 
>>> Wind 
>>> entry. If you look at the Statistics report below it still shows N/A 
>>> for 
>>> Max Wind degrees for Day and Week but for Month and Year (presumably 
>>> data 
>>> from 4.5.1) a degree value is reported.
>>>
>>> [image: Max Wind.jpg]
>>> Any suggestions?
>>>
>>> Paul
>>> On Sunday, 13 February 2022 at 15:04:26 UTC asla...@gmail.com wrote:
>>>
 Brilliant, now it work just fine.
 Thanks a lot.

 On Sunday, February 13, 2022 at 3:28:45 PM UTC+1 
 remy.l...@gmail.com wrote:

> Yes !! Thank-you Tom it works great now :
>
> [image: Capture d’écran de 2022-02-13 15-26-27.png]
> Le dimanche 13 février 2022 à 14:33:57 UTC+1, 

Re: [weewx-user] windGustDir is always set to NULL in database after upgrating to weewx version 4.6.0/4.6.2

[Aslak Vaa]

I have installed your last update, and I will keep an eye on the results 
for the next days. Thank you for following up the issue.

However, I performed queries from the accumulator tables for windSpeed, 
windDir, windGust and windGustDir. The mintime/maxtime for wind and 
direction are unequal both for windSpeed/windDir and windGust/windGustDir 
min/max values.
I expected that the min/max values of windDir/windGustDir should be the 
values at the same mintime/maxtime as the corresponding min/max for 
windSpeed/windGust  values. This is not the case.
Is this an error or a feature?
Please find queries and results in enclosed file.

Best Regards, Aslak

On Tuesday, February 22, 2022 at 12:20:53 AM UTC+1 tke...@gmail.com wrote:

> Upon reflection, I really didn't like the solution I posted earlier. The 
> reality is that for stations that do not supply windGustDir, such as the 
> Fine Offset stations, weewx was calculating a substitute just fine: the 
> vector average of the wind over an archive period was being extracted from 
> the accumulators. The problem is that because of the peculiarities of how 
> WXXTypes was set up, it was forcing windGustDir to None if windGustDir was 
> missing, which caused the calculated value not to get substituted. Then I 
> supplied a band-aid over this by substituting windDir instead.
>
> A mess.
>
> With commit 244a7f8 
> ,
>  
> I've changed this to do nothing in WXXTypes if windGustDir is missing. This 
> causes a value to be successfully extracted from the accumulators.
>
> A long-winded way to say that I think the new solution is a better, more 
> accurate one.
>
> If you're comfortable using git, I'd appreciate it if one of you FO owners 
> could give it a try.
>
> -tk
>
>
>
> On Mon, Feb 14, 2022 at 3:46 AM paul...@gmail.com  
> wrote:
>
>> Checked this morning and pleased to say Max Wind direction is now 
>> reporting and updating in the Day tab of the Statistics section. Still N/A 
>> in Week but I'm guessing it will update in due course.
>> Just out of interest I've noticed in the Statistics section the Year tab 
>> is blue and if you click on it you get the option of Year or Rain Year. 
>> What actually is the difference between these two? In my case the values 
>> reported are identical.
>> Paul
>>
>> On Sunday, 13 February 2022 at 20:01:25 UTC remy.l...@gmail.com wrote:
>>
>>> Yes, it’s the good python file, same as me  (if standard installation...)
>>> The Tom’s update/patch solves perfectly the problem and also min/max 
>>> windGustDir data base.
>>> Try stop and start weewx (logicaly same thing as restart... !?)
>>> Try to look for all wxxtype.py on your system to see if there is another 
>>> file ? Logicaly no...
>>>
>>>
>>> Le dimanche 13 février 2022 à 20:23:07 UTC+1, paul...@gmail.com a 
>>> écrit :
>>>
 Hi Remy
 Yes I did sudo /etc/init.d/weewx restart. Just in case I've done it 
 again but no change.
 Can I just check I swapped the correct wxxtypes.py file. I swapped the 
 one in /usr/share/weewx/weewx
 Paul

 On Sunday, 13 February 2022 at 18:08:44 UTC remy.l...@gmail.com wrote:

> Hi Paul.
> Have you triedto stop weewx and restart it ?
> You must do that if you modify python file.
> Cordialy 
>
>
> Le dimanche 13 février 2022 à 18:32:38 UTC+1, paul...@gmail.com a 
> écrit :
>
>> I don't report wind gust values/direction in the Current Conditions 
>> section of my Seasons skin (version 4.6.2) but in the Statistics 
>> (previously High/Low) section I've always had a Max Wind entry with both 
>> speed and direction reported. Since 4.6.2 the direction is reported as 
>> N/A 
>> so I've followed this thread and replaced the wxxtypes.py file with the 
>> new 
>> one from Tom but it doesn't seem to have made any difference to my Max 
>> Wind 
>> entry. If you look at the Statistics report below it still shows N/A for 
>> Max Wind degrees for Day and Week but for Month and Year (presumably 
>> data 
>> from 4.5.1) a degree value is reported.
>>
>> [image: Max Wind.jpg]
>> Any suggestions?
>>
>> Paul
>> On Sunday, 13 February 2022 at 15:04:26 UTC asla...@gmail.com wrote:
>>
>>> Brilliant, now it work just fine.
>>> Thanks a lot.
>>>
>>> On Sunday, February 13, 2022 at 3:28:45 PM UTC+1 remy.l...@gmail.com 
>>> wrote:
>>>
 Yes !! Thank-you Tom it works great now :

 [image: Capture d’écran de 2022-02-13 15-26-27.png]
 Le dimanche 13 février 2022 à 14:33:57 UTC+1, tke...@gmail.com a 
 écrit :

> I was able to replicate the problem. Pre V4.6, if windGustDir was 
> missing, windDir was substituted. That behavior went away with v4.6. 
> This 
> patch restores it.
>
> Index: bin/weewx/wxxtypes.py
> 

[weewx-user] live_data.json will not be created correct

['Martin' via weewx-user]

Hello, I have installed the latest version of
https://github.com/gjr80/weewx-realtime_gauge-data
and the PHP file from
https://github.com/wrybread/weewx-realtime_gauge-data

to create the live_data.json from gauge-data.txt.

The live_data.json will be created but it is empty (only []).

What can I do to get a filled live_data.json?
Thank you!
Regards,
Martin

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ec300e8a-e99d-4871-aa79-b16401df94f4n%40googlegroups.com.

[weewx-user] Re: 4.6.2. update problem with wee_import

[jannep...@gmail.com]

Gary,

yes, my mistake! I used the wrong version of weeimport.py while I was 
returning the original. I have many... Thanks for advising me. Sorry.

Now everything works and I could import data! Your patch was working great.

Thank you! You are really doing a good work!

best regards
Janne 


tiistai 22. helmikuuta 2022 klo 12.17.31 UTC+2 gjr80 kirjoitti:

> Janne,
>
> "It doesn't work" is not very helpful. Please return weeimport.py to it's 
> original 4.6.2 state, ensure you have the patched weeutil.py and then run 
> the import again. Please post an exact copy of the console output including 
> the command issued and responses/error traces.
>
> Gary
>
> On Tuesday, 22 February 2022 at 18:55:59 UTC+10 jannep...@gmail.com wrote:
>
>> Gary,
>>
>> Thanks!
>> I installed the patch, but it did not help. I also tried to uncomment my 
>> own fix from weeimport.py, (the fix which you don't recommend to do...) but 
>> that returned my first problem back.
>>
>> My original date.csv has datetime format as in my csv.conf 
>> raw_datetime_format expect. Thanks anyway. 
>>
>> Janne
>>
>> tiistai 22. helmikuuta 2022 klo 4.42.37 UTC+2 gjr80 kirjoitti:
>>
>>> Janne,
>>>
>>> You've encountered a bug that shows when wee_import is run under python 
>>> 2 using a user defined field map. The fix required was not to wee_import 
>>> but elsewhere in WeeWX and will appear in the next release (expected to be 
>>> 4.6.3). In the meantime since you are using WeeWX v4.6.2 you can safely 
>>> just download the patched file, replace the corresponding file on your 
>>> system and wee_import should work fine. To download and install the 
>>> patched file:
>>>
>>> 1. move aside the file to be patched:
>>> $ mv /usr/share/weewx/weeutil/weeutil.py 
>>> /usr/share/weewx/weeutil/weeutil_orig.py
>>>
>>> 2. download the patched file:
>>> $ wget -P /usr/share/weewx/weeutil/ 
>>> https://raw.githubusercontent.com/weewx/weewx/master/bin/weeutil/weeutil.py
>>>
>>> 3. stop WeeWX (if it is running) and perform your import
>>>
>>> I did a test import using the patched file, your import config file and 
>>> your CSV data. The raw_datetime_format setting in your import config 
>>> file needs to be changed to match the format of the date-time field your 
>>> are using in your source data, it needs to be set as follows:
>>>
>>> raw_datetime_format = "%d.%m.%y %H:%M"
>>>
>>> With this change your data imported correctly and with out error. Note 
>>> that you will likely receive the following message during the import:
>>>
>>> Warning: Import field 'gustDir' is mapped to WeeWX field 'windGustDir' 
>>> but the
>>>  import field 'gustDir' could not be found in one or more 
>>> records.
>>>  WeeWX field 'windGustDir' will be set to 'None' in these 
>>> records.
>>>
>>> This is just a warning that you have a mapped field for which there is 
>>> no source data. It can be safely ignored. 
>>>
>>> Gary
>>>
>>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a6dbe838-a328-4576-8c3f-ec6e1284a827n%40googlegroups.com.

Re: [weewx-user] Update Problem

[Tom Keffer]

The configuration file (skin.conf) for the Smartphone skin is specifying a
template (iv.html.tmpl), which does not exist. This template is not part of
weewx. If it ever existed, it was supplied by you or someone else.

However, I noticed that the path to the template is non-standard. The log
indicates /etc/weewx/skins/Smartphone/smartphone/uv.html.tmpl, but the more
usual location would be /etc/weewx/skins/Smartphone/uv.html.tmpl. Perhaps
the path, as specified in skin.conf, is wrong?



On Tue, Feb 22, 2022 at 1:42 AM ried...@gmail.com 
wrote:

> Hello
> After the update from Weex 4.5.2 to 4.6.2 I only have 2 sensors in the
> list.
> outside temperature and air pressure.
> I am using an HP1000 driver.
> There are also some error messages in the sys log!
> Skin unknown unknown although I specified standard in the config.
> Here is an excerpt from the log
>
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  Traceback (most recent call last):
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  File "/usr/share/weewx/weewx/cheetahgenerator.py", line 328, in generate
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  compiled_template = Cheetah.Template.Template(
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1337, in
> __init__
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  self._compile(source, file, compilerSettings=compilerSettings)
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1631, in
> _compile
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  self._fileMtime = os.path.getmtime(file)
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  File "/usr/lib/python3.8/genericpath.py", line 55, in getmtime
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  return os.stat(filename).st_mtime
> Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator: 
>  FileNotFoundError: [Errno 2] No such file or directory:
> '/etc/weewx/skins/Smartphone/smartphone/uv.html.tmpl'
> Feb 22 10:40:34 weewx weewx[6490] INFO weewx.cheetahgenerator: Generated 6
> files for report SmartphoneReport in 0.22 seconds
> Feb 22 10:40:35 weewx weewx[6490] INFO weewx.imagegenerator: Generated 6
> images for report SmartphoneReport in 0.33 seconds
> Feb 22 10:40:35 weewx weewx[6490] INFO weewx.reportengine: Copied 0 files
> to /var/www/html/weewx/smartphone
> Feb 22 10:40:35 weewx weewx[6490] INFO weewx.reportengine: ftpgenerator:
> Ftp'd 30 files in 0.31 seconds
>
>
> I hope this problem can be solved.
>
> Regards
> Andre
>
> --
> 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 weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/7f0a6c8a-43bb-4871-8690-fb1a9b8bae91n%40googlegroups.com
> 
> .
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEAyfZKMkeUTb4tvaYi_OaM2GSLqgjkMp8mHub9GeCxcaQ%40mail.gmail.com.

[weewx-user] Re: 4.6.2. update problem with wee_import

[gjr80]

Janne,

"It doesn't work" is not very helpful. Please return weeimport.py to it's 
original 4.6.2 state, ensure you have the patched weeutil.py and then run 
the import again. Please post an exact copy of the console output including 
the command issued and responses/error traces.

Gary

On Tuesday, 22 February 2022 at 18:55:59 UTC+10 jannep...@gmail.com wrote:

> Gary,
>
> Thanks!
> I installed the patch, but it did not help. I also tried to uncomment my 
> own fix from weeimport.py, (the fix which you don't recommend to do...) but 
> that returned my first problem back.
>
> My original date.csv has datetime format as in my csv.conf 
> raw_datetime_format expect. Thanks anyway. 
>
> Janne
>
> tiistai 22. helmikuuta 2022 klo 4.42.37 UTC+2 gjr80 kirjoitti:
>
>> Janne,
>>
>> You've encountered a bug that shows when wee_import is run under python 
>> 2 using a user defined field map. The fix required was not to wee_import 
>> but elsewhere in WeeWX and will appear in the next release (expected to be 
>> 4.6.3). In the meantime since you are using WeeWX v4.6.2 you can safely 
>> just download the patched file, replace the corresponding file on your 
>> system and wee_import should work fine. To download and install the 
>> patched file:
>>
>> 1. move aside the file to be patched:
>> $ mv /usr/share/weewx/weeutil/weeutil.py 
>> /usr/share/weewx/weeutil/weeutil_orig.py
>>
>> 2. download the patched file:
>> $ wget -P /usr/share/weewx/weeutil/ 
>> https://raw.githubusercontent.com/weewx/weewx/master/bin/weeutil/weeutil.py
>>
>> 3. stop WeeWX (if it is running) and perform your import
>>
>> I did a test import using the patched file, your import config file and 
>> your CSV data. The raw_datetime_format setting in your import config 
>> file needs to be changed to match the format of the date-time field your 
>> are using in your source data, it needs to be set as follows:
>>
>> raw_datetime_format = "%d.%m.%y %H:%M"
>>
>> With this change your data imported correctly and with out error. Note 
>> that you will likely receive the following message during the import:
>>
>> Warning: Import field 'gustDir' is mapped to WeeWX field 'windGustDir' 
>> but the
>>  import field 'gustDir' could not be found in one or more records.
>>  WeeWX field 'windGustDir' will be set to 'None' in these records.
>>
>> This is just a warning that you have a mapped field for which there is no 
>> source data. It can be safely ignored. 
>>
>> Gary
>>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/143f8ab6-c87c-4be8-9743-40b8c01b773en%40googlegroups.com.

[weewx-user] Update Problem

[ried...@gmail.com]

Hello
After the update from Weex 4.5.2 to 4.6.2 I only have 2 sensors in the list.
outside temperature and air pressure.
I am using an HP1000 driver.
There are also some error messages in the sys log!
Skin unknown unknown although I specified standard in the config.
Here is an excerpt from the log

Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 Traceback (most recent call last):
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:    
 File "/usr/share/weewx/weewx/cheetahgenerator.py", line 328, in generate
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 compiled_template = Cheetah.Template.Template(
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:    
 File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1337, in 
__init__
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 self._compile(source, file, compilerSettings=compilerSettings)
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:    
 File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1631, in 
_compile
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 self._fileMtime = os.path.getmtime(file)
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:    
 File "/usr/lib/python3.8/genericpath.py", line 55, in getmtime
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 return os.stat(filename).st_mtime
Feb 22 10:40:34 weewx weewx[6490] ERROR weewx.cheetahgenerator:  
 FileNotFoundError: [Errno 2] No such file or directory: 
'/etc/weewx/skins/Smartphone/smartphone/uv.html.tmpl'
Feb 22 10:40:34 weewx weewx[6490] INFO weewx.cheetahgenerator: Generated 6 
files for report SmartphoneReport in 0.22 seconds
Feb 22 10:40:35 weewx weewx[6490] INFO weewx.imagegenerator: Generated 6 
images for report SmartphoneReport in 0.33 seconds
Feb 22 10:40:35 weewx weewx[6490] INFO weewx.reportengine: Copied 0 files 
to /var/www/html/weewx/smartphone
Feb 22 10:40:35 weewx weewx[6490] INFO weewx.reportengine: ftpgenerator: 
Ftp'd 30 files in 0.31 seconds


I hope this problem can be solved.

Regards
Andre

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/7f0a6c8a-43bb-4871-8690-fb1a9b8bae91n%40googlegroups.com.

Re: [weewx-user] 4.6.x RPMs fail PGP signature validation

[mbat...@gmail.com]

Lucky SO(?)!


On Monday, February 21, 2022 at 7:34:25 AM UTC-6 tke...@gmail.com wrote:

> Matthew Wall signed the last couple of releases. He may have used a 
> different signature. If he did, I don't have access to it, and he is on a 
> small boat in the Caribbean until the end of the month. I'll see if I can 
> contact him.
>
> -tk
>
> On Mon, Feb 21, 2022 at 12:24 AM Scott Shambarger  
> wrote:
>
>> Hi,
>>
>> FYI, all the 4.6.x rpms fail PGP signature validation. The tkeffer key on 
>> weewx.com/keys.html (keyid a0cb255b75bf977c) has signed all previous 
>> releases, but rpms since 4.6.0 are all signed with an unpublished keyid of 
>> 50abae5f15306a67.
>>
>> With a yum/dnf repo configured with gpgcheck=1 this prevents new releases 
>> from passing validation.  Is there a new source for the signing key?
>>
>> Thanks,
>> Scott
>>
>> -- 
>> 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 weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/570ff1e2-6bbc-482f-9dea-e2a2f279511cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/269855e0-287e-4503-bcbf-4348d734189en%40googlegroups.com.

[weewx-user] Re: 4.6.2. update problem with wee_import

[jannep...@gmail.com]

Gary,

Thanks!
I installed the patch, but it did not help. I also tried to uncomment my 
own fix from weeimport.py, (the fix which you don't recommend to do...) but 
that returned my first problem back.

My original date.csv has datetime format as in my csv.conf 
raw_datetime_format expect. Thanks anyway. 

Janne

tiistai 22. helmikuuta 2022 klo 4.42.37 UTC+2 gjr80 kirjoitti:

> Janne,
>
> You've encountered a bug that shows when wee_import is run under python 2 
> using a user defined field map. The fix required was not to wee_import 
> but elsewhere in WeeWX and will appear in the next release (expected to be 
> 4.6.3). In the meantime since you are using WeeWX v4.6.2 you can safely 
> just download the patched file, replace the corresponding file on your 
> system and wee_import should work fine. To download and install the 
> patched file:
>
> 1. move aside the file to be patched:
> $ mv /usr/share/weewx/weeutil/weeutil.py 
> /usr/share/weewx/weeutil/weeutil_orig.py
>
> 2. download the patched file:
> $ wget -P /usr/share/weewx/weeutil/ 
> https://raw.githubusercontent.com/weewx/weewx/master/bin/weeutil/weeutil.py
>
> 3. stop WeeWX (if it is running) and perform your import
>
> I did a test import using the patched file, your import config file and 
> your CSV data. The raw_datetime_format setting in your import config file 
> needs to be changed to match the format of the date-time field your are 
> using in your source data, it needs to be set as follows:
>
> raw_datetime_format = "%d.%m.%y %H:%M"
>
> With this change your data imported correctly and with out error. Note 
> that you will likely receive the following message during the import:
>
> Warning: Import field 'gustDir' is mapped to WeeWX field 'windGustDir' but 
> the
>  import field 'gustDir' could not be found in one or more records.
>  WeeWX field 'windGustDir' will be set to 'None' in these records.
>
> This is just a warning that you have a mapped field for which there is no 
> source data. It can be safely ignored. 
>
> Gary
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ad8f32e3-727e-46e6-acb1-8348a1aba4e7n%40googlegroups.com.