Re: [weewx-user] wee_import - dateTime not converting/importing properly

[William]

Gary, this worked perfectly! Thank you! Now to import 6.9 million rows of 
data :) 



On Saturday, March 11, 2023 at 9:13:37 PM UTC-5 gjr80 wrote:

> Fixed at commit 036b9b1 
> 
>  
> to appear in WeeWX v5.0.0 when released (or v4.10.3 should such a release 
> occur).
>
> In the interim, if you are using WeeWX v4.9.0 or later you can use the 
> updated wee_import files as follows:
>
> 1. Move aside the existing weeimport.py as follows (depending on your 
> install you may need to prefix the following commands with sudo):
>
> $ mv 
> /home/weewx/bin/weeimport/weeimport.py 
> /home/weewx/bin/weeimport/weeimport_orig.py
> for setup.py installs or
> $ mv 
> /usr/share/weewx/weeimport/weeimport.py 
> /usr/share/weewx/weeimport/weeimport_orig.py
> for package installs
>
> 2. Download the updated weeimport.py (depending on your install you may 
> need to prefix the following commands with sudo):
>
> $ wget -P /home/weewx/bin/weeimport/ 
> https://raw.githubusercontent.com/weewx/weewx/issue_856_wee_import_dateTime/bin/weeimport/weeimport.py
> for setup.py installs or 
> $ wget -P /usr/share/weewx/wee import/ 
> https://raw.githubusercontent.com/weewx/weewx/issue_856_wee_import_dateTime/bin/weeimport/weeimport.py
> for package installs
>
> 3. Perform your import, wee_import should now allow importing numeric 
> only non-unix epoch timestamps using a date-time format string such as 
> %Y%m%d%H%M. Users are strongly advised to use the --dry-run command line 
> option when first running wee_import to confirm that date-time data is 
> correctly parsed. The WeeWX log (by default weewx.log) should be checked 
> after the import to ensure data was correctly imported.
>
> Note also that the delimiter setting in the csv import config file must be 
> enclosed in quotes, eg delimiter = ','. The existing example csv import 
> config file and the wee_import documentation does not mention this 
> requirement.
>
> Documentation will be updated in due course for the v5.0.0 release.
>
> Gary
>
> On Sunday, 12 March 2023 at 03:26:08 UTC+10 William wrote:
>
>> Thanks Ranier to you and Gary both for the replies. I was fairly sure I 
>> tried dropping the unix_epoch unit last night and got the same result, but 
>> just tried it again to confirm. My data originated from the old 
>> AmbientWeather Virtual Weather Station software that conveniently dumped 
>> the data to an easily-readable CSV that I could ingest into a database, and 
>> the CSV files I'm using for wee_import are simply a dump from this SQL 
>> database back into CSV format. My hopes are to eliminate this older, 
>> no-longer-supported software and Windows altogether (and my scripts to get 
>> this data into a database), and go with a Linux-supported software that is 
>> continued to be routinely updated, like weewx.
>>
>> Here's the header and two first rows of data for 2011-05-06 at 09:57 and 
>> 09:58.
>>
>>
>> "RecDate","WindDir","WindSpeed","WindGust","IndoorHumidity","OutdoorHumidity","IndoorTemperature","OutdoorTemperature","BarometricPressure","TotalRain","CH1Temperature","CH1Humidity","CH2Temperature","CH2Humidity","CH3Temperature","CH3Humidity","Evapotranspiration","UVindex","SolarRadiation","WindChill","IndoorHeatIndex","OutdoorHeatIndex","DewPoint","SeaLevelPressure","PressureAltitude","CloudBase","AirDensity","VirtualTemperature","VaporPressure","WindDirRate","WindSpeedRate","WindGustRate","IndoorHumidityRate","OutdoorHumidityRate","IndoorTemperatureRate","OutdoorTemperatureRate","BarometricPressureRate","TotalRainRate","CH1TemperatureRate","CH1HumidityRate","CH2TemperatureRate","CH2HumidityRate","CH3TemperatureRate","CH3HumidityRate","EvapotranspirationRate","UVindexRate","SolarRadiationRate","WindChillRate","IndoorHeatIndexRate","OutdoorHeatIndexRate","DewPointRate","SeaLevelPressureRate","RainDaily","RainHourly","Last24HrRain","RainRate","WindRunDaily","DegDaysHeatingDaily","DegDaysCoolingDaily","MoonPhase","MonthlyRain","DegDaysHeatingMonthly","DegDaysCoolingMonthly","WindRunMonthly","DegDaysHeatingYearly","DegDaysCoolingYearly","WindRunYearly"
>>
>> "201105060957","0.000","0.000","0.000","38.000","73.000","74.500","49.600","30.009","0.010","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","5.000","49.600","74.270","52.921","41.313","30.009","-82.216","2071.683","-708.443","51.277","0.261","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.100","0.096","0.000","0.010","0.000","0.000","0.000","0.000","0.011","0.000","3.094","0.010","0.011","0.000","0.000","0.011","0.000","0.000"
>>
>> 

[weewx-user] Rain + rain rate instead of hourly rain?

[paulth...@gmail.com]

I recently replaced my old WH3081 weather station with a HP2551.

Updating weewx to use the new weather station was fairly smooth,
but I had to switch to the "Seasons" skin to get readings from all of
the sensors (e.g. soil moisture sensor) displayed.

Ideally, I'd love to replace the hourly rainfall graph with a 5/10 minute
rain + rainfall rate graph.  I don't know what I'm doing wrong; it seems
like a simple configuration change, but all I get is NOPE.  :-)

Any advice would be greatly appreciated.

Cheers!
Paul.

-- 
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/604e2297-9420-4748-9c38-c4c88f6a6933n%40googlegroups.com.

Re: [weewx-user] Date/time formatting for aggregation like "maxsum"

[michael.k...@gmx.at]

Great, thanks! After all that java, spring, ... during the week, it's not 
so easy to see the sometimes easiest solutions in another world, thanks 
again for your inputs.

Tom Keffer schrieb am Sonntag, 12. März 2023 um 00:17:15 UTC+1:

> Look through the list of strftime() formats I linked to and see if 
> anything fits your needs. For example, the rest of WeeWX uses %x and %X.
>
> On Sat, Mar 11, 2023 at 11:40 AM michael.k...@gmx.at  
> wrote:
>
>> That was kind of what I intended to do, but while for $week using "%A" 
>> may be OK, using "%m/%d%Y", won't fit in many localizations. Is there a 
>> default format for date without time that I should reference or should I 
>> just add such the format for the sums setting to each lang file? 
>>
>> Tom Keffer schrieb am Freitag, 10. März 2023 um 22:18:12 UTC+1:
>>
>>> Yes, the query is not as optimal as it could be. It's returning the 
>>> right date, but the time at which maximum rainfall was achieved, rather 
>>> than midnight. 
>>>
>>> You can solve your problem by applying a formatting. For example,
>>>
>>> *$week.rain.maxsumtime.format("%A"), $month.rain.maxsumtime("%m/%d/%Y), 
>>> ...*
>>>
>>>
>>> The formatting is from Python's strftime() function 
>>> 
>>> .
>>>
>>> On Fri, Mar 10, 2023 at 6:03 AM michael.k...@gmx.at  
>>> wrote:
>>>
 When I calculate "maxsum" as the maximum daily rain sum per 
 week/month/year/alltime, I am a bit confused by the output when it comes 
 to 
 formatting the date/time for the value. 

 For me, having a time for a maximum daily sum doesn't make sense in 
 this context.

 So, How can I solve this? I couldn't find out so far, if I can specifiy 
 a special time format for aggregations like "maxsum"

 In the template I use $week.rain.maxsumtime, $month.rain.maxsumtime, 
 $year.rain.maxsumtime, $alltime.rain.maxsumtime. The used format makes 
 sense for max, min, maxmin, minmax, but not for a sum.

 How can I make the web page show "Wednesday" for "This week", 
 "03/08/2023" for "This month, etc, without the hh:mm:ss added? 

 [image: 2023-03-10 14_48_03-The weather in Test - Brave.png]

 -- 
 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/beb4ca00-11f5-4758-bb89-17aec6b2a956n%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/0271fd51-a86b-40e7-a242-4eb2661b166an%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/8c799145-94e5-4f22-9618-e776d982e2fan%40googlegroups.com.

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

Adding a second change will correct the bottom_label if I'm using my new 
time_offest - simply subtract the offset in line 175 from plotgin_ts:
# Get a suitable bottom label:
bottom_label_format = plot_options.get('bottom_label_format', 
'%m/%d/%y %H:%M')
bottom_label = time.strftime(bottom_label_format, time.localtime(
plotgen_ts - int(plot_options.get('time_offset', 0
plot.setBottomLabel(bottom_label)

Not a very elegant approach (to have this calculation at 2 places within 
the code), but it works fine.

Regards, Michael


Michael Waldor schrieb am Samstag, 11. März 2023 um 17:29:34 UTC+1:

> I've digged a little bit within source code of weewx - especially 
> bin/weewx/imagegenerator.py
>
> My goal is to shift the timeline by an offset so that I can render data 
> from the "future" (from the DWD forecast). And to my surprise it's really 
> simple to introduce the new option time_offset by adding only one line of 
> code into imagegenerator.py
> ...
> # Calculate a suitable min, max time for the requested time.
>
> plotgen_ts = plotgen_ts + int(plot_options.get('time_offset', 0))
>
> minstamp, maxstamp, timeinc = weeplot.utilities.scaletime(
> plotgen_ts - int(plot_options.get('time_length', 86400)), 
> plotgen_ts)
> x_domain = weeutil.weeutil.TimeSpan(minstamp, maxstamp)
> ...
> Within skin.conf I've added this "new" option time_offset = 259200 (3 
> days), and I get the intended shift of the timeline by 3 days (see appended 
> image).
>
> The only disadvantage is that the timestamp printed below the image is 
> shifted, too. But I think that is by design (same for wee_report with 
> timestamp option).
>
> My suggestion: Please include my small change within the next release of 
> weewx.
>
> Regards, Michael
>
>
> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 16:45:07 UTC+1:
>
>> I've done more experiments w.r.t. time_enght - if I increase its value by 
>> 1s from the default 27h I get an imagecoverring 48h (instead of 27h plus 
>> 1s). Thus the value 97200 is kind of magic to deliver the expected 27h, but 
>> it's not possible to increase the value even a little bit. See my appended 
>> picture with time_length = 97201.
>>
>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 15:46:06 UTC+1:
>>
>>> Another experiment with the (new) DWD SQlite database - sadly failing:
>>>
>>> From weewx customization guide I've learned that one might use (simple 
>>> SQL) expressions to calculate new data within image generation. I gave it a 
>>> try to calculate the windChill from the available SQL data like
>>> [[[daytempfeel]]]
>>> windchill
>>> heatindex
>>> forecast_windchill
>>> data_type = windchillMetric(outTemp, windSpeed)
>>> data_binding = dwd_binding
>>> label = ' '
>>> color = red
>>> That stopped the image generator from further processing. Is this 
>>> somehow possible?
>>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:
>>>
 Thanks for that hint - currently I'm still experimenting with this new 
 functionality.

 In the meantime I could resolve my problem with seasons.css - it was a 
 problem with caching within firefox. Even after deletion of 
 /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
 But when new images have been generated the missing seasons.css become 
 obvious, and a new seasons.css will be used. Thus one problem solved!


 Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:

> I do the image size change at the top level, so that all images are 
> the same size.  I am not sure what happens if only one image is larger.
>
> I tested with Firefox (windows x64) and Apache server.
>
> Use F12 and inspect where the size directive is coming from, if you 
> feel brave.
>
> On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:
>
>>
>> Thanks for your quich reply. Changing the image size works fine in 
>> skin.conf, but modifing seasons.css (for testing purpose at 
>> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
>> within firefox dspite reload?
>>
>> This is my current (testing) status within skin.conf - image sizes 
>> currently intentionally commented:
>>
>> [[[daytempdew]]] 
>>
>> # image_width = 600   
>>   
>> #image_height = 180   
>>  
>> outTemp   
>>  
>> data_type = outTemp  
>> data_binding = wx_binding
>> dewpoint  

Re: [weewx-user] wee_import

[gjr80]

Correct, a zero length list.

On Sunday, 12 March 2023 at 12:09:26 UTC+10 Graham Eddy wrote:

> isn’t this parsed as a list?
> *⊣GE⊢*
>
> On 12 Mar 2023, at 12:28 pm, gjr80  wrote:
>
>  delimiter = ,
>
>
>

-- 
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/4fd03493-5855-4a60-ba87-20472df1d713n%40googlegroups.com.

Re: [weewx-user] wee_import - dateTime not converting/importing properly

[gjr80]

Fixed at commit 036b9b1 

 
to appear in WeeWX v5.0.0 when released (or v4.10.3 should such a release 
occur).

In the interim, if you are using WeeWX v4.9.0 or later you can use the 
updated wee_import files as follows:

1. Move aside the existing weeimport.py as follows (depending on your 
install you may need to prefix the following commands with sudo):

$ mv 
/home/weewx/bin/weeimport/weeimport.py 
/home/weewx/bin/weeimport/weeimport_orig.py
for setup.py installs or
$ mv 
/usr/share/weewx/weeimport/weeimport.py 
/usr/share/weewx/weeimport/weeimport_orig.py
for package installs

2. Download the updated weeimport.py (depending on your install you may 
need to prefix the following commands with sudo):

$ wget -P 
/home/weewx/bin/weeimport/ 
https://raw.githubusercontent.com/weewx/weewx/issue_856_wee_import_dateTime/bin/weeimport/weeimport.py
for setup.py installs or 
$ wget -P /usr/share/weewx/wee 
import/ 
https://raw.githubusercontent.com/weewx/weewx/issue_856_wee_import_dateTime/bin/weeimport/weeimport.py
for package installs

3. Perform your import, wee_import should now allow importing numeric only 
non-unix epoch timestamps using a date-time format string such as %Y%m%d%H%M. 
Users are strongly advised to use the --dry-run command line option when 
first running wee_import to confirm that date-time data is correctly 
parsed. The WeeWX log (by default weewx.log) should be checked after the 
import to ensure data was correctly imported.

Note also that the delimiter setting in the csv import config file must be 
enclosed in quotes, eg delimiter = ','. The existing example csv import 
config file and the wee_import documentation does not mention this 
requirement.

Documentation will be updated in due course for the v5.0.0 release.

Gary

On Sunday, 12 March 2023 at 03:26:08 UTC+10 William wrote:

> Thanks Ranier to you and Gary both for the replies. I was fairly sure I 
> tried dropping the unix_epoch unit last night and got the same result, but 
> just tried it again to confirm. My data originated from the old 
> AmbientWeather Virtual Weather Station software that conveniently dumped 
> the data to an easily-readable CSV that I could ingest into a database, and 
> the CSV files I'm using for wee_import are simply a dump from this SQL 
> database back into CSV format. My hopes are to eliminate this older, 
> no-longer-supported software and Windows altogether (and my scripts to get 
> this data into a database), and go with a Linux-supported software that is 
> continued to be routinely updated, like weewx.
>
> Here's the header and two first rows of data for 2011-05-06 at 09:57 and 
> 09:58.
>
>
> "RecDate","WindDir","WindSpeed","WindGust","IndoorHumidity","OutdoorHumidity","IndoorTemperature","OutdoorTemperature","BarometricPressure","TotalRain","CH1Temperature","CH1Humidity","CH2Temperature","CH2Humidity","CH3Temperature","CH3Humidity","Evapotranspiration","UVindex","SolarRadiation","WindChill","IndoorHeatIndex","OutdoorHeatIndex","DewPoint","SeaLevelPressure","PressureAltitude","CloudBase","AirDensity","VirtualTemperature","VaporPressure","WindDirRate","WindSpeedRate","WindGustRate","IndoorHumidityRate","OutdoorHumidityRate","IndoorTemperatureRate","OutdoorTemperatureRate","BarometricPressureRate","TotalRainRate","CH1TemperatureRate","CH1HumidityRate","CH2TemperatureRate","CH2HumidityRate","CH3TemperatureRate","CH3HumidityRate","EvapotranspirationRate","UVindexRate","SolarRadiationRate","WindChillRate","IndoorHeatIndexRate","OutdoorHeatIndexRate","DewPointRate","SeaLevelPressureRate","RainDaily","RainHourly","Last24HrRain","RainRate","WindRunDaily","DegDaysHeatingDaily","DegDaysCoolingDaily","MoonPhase","MonthlyRain","DegDaysHeatingMonthly","DegDaysCoolingMonthly","WindRunMonthly","DegDaysHeatingYearly","DegDaysCoolingYearly","WindRunYearly"
>
> "201105060957","0.000","0.000","0.000","38.000","73.000","74.500","49.600","30.009","0.010","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","5.000","49.600","74.270","52.921","41.313","30.009","-82.216","2071.683","-708.443","51.277","0.261","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.100","0.096","0.000","0.010","0.000","0.000","0.000","0.000","0.011","0.000","3.094","0.010","0.011","0.000","0.000","0.011","0.000","0.000"
>
> 

Re: [weewx-user] wee_import

[Graham Eddy]

isn’t this parsed as a list?
⊣GE⊢

> On 12 Mar 2023, at 12:28 pm, gjr80  wrote:
> 
>  delimiter = ,

-- 
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/40AFBA0A-B077-4F4A-8614-14109D231389%40geddy.au.

[weewx-user] Re: wee_import

[gjr80]

It seem's something has changed and the delimiter now needs to be enclosed 
in quotes in the import config file. In your import config file find the 
line:

delimiter = ,

and change it to:

delimiter = ","

Try running your import again. I will make the necessary changes to the 
example import config files and documentation.

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/f6c9824d-a812-4c9d-8a6d-9643e9924c8bn%40googlegroups.com.

Re: [weewx-user] week_start

[stefa...@gmail.com]

This is good to know. Thanks Tom!

On Saturday, 11 March 2023 at 18:24:32 UTC-5 Tom Keffer wrote:

> The start-of-week is used only in reporting, not in archiving, so feel 
> free to change it at any time.
>
> However, you might want to regenerate all your reports so you know they're 
> consistent. Simply delete them, and WeeWX will regenerate at the next 
> reporting cycle.
>
> -tk
>
> On Sat, Mar 11, 2023 at 2:56 PM stefa...@gmail.com  
> wrote:
>
>> I've been running Weewx for years and I'm considering on changing week 
>> start to Monday (0) in the station section of weewx.conf. It is currently 
>> set to Sunday (6). Does anyone know of any implications to changing it in 
>> regards to reporting? 
>> It might seem insignificant but what day does everyone else use?
>>
>> Thanks!
>> Stefan
>>
>> -- 
>> 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/702b5ecb-e903-4b46-a454-4181a6dc4321n%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/df2fc24c-b838-487a-b536-8c10292a2322n%40googlegroups.com.

Re: [weewx-user] week_start

[Tom Keffer]

The start-of-week is used only in reporting, not in archiving, so feel free
to change it at any time.

However, you might want to regenerate all your reports so you know they're
consistent. Simply delete them, and WeeWX will regenerate at the next
reporting cycle.

-tk

On Sat, Mar 11, 2023 at 2:56 PM stefa...@gmail.com 
wrote:

> I've been running Weewx for years and I'm considering on changing week
> start to Monday (0) in the station section of weewx.conf. It is currently
> set to Sunday (6). Does anyone know of any implications to changing it in
> regards to reporting?
> It might seem insignificant but what day does everyone else use?
>
> Thanks!
> Stefan
>
> --
> 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/702b5ecb-e903-4b46-a454-4181a6dc4321n%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/CAPq0zEAcZKbV9BR9g6wD8Pp-oE7tj4M89jvqdfnKUz7pLVYRaw%40mail.gmail.com.

Re: [weewx-user] Date/time formatting for aggregation like "maxsum"

[Tom Keffer]

Look through the list of strftime() formats I linked to and see if anything
fits your needs. For example, the rest of WeeWX uses %x and %X.

On Sat, Mar 11, 2023 at 11:40 AM michael.k...@gmx.at <
michael.kainzba...@gmx.at> wrote:

> That was kind of what I intended to do, but while for $week using "%A" may
> be OK, using "%m/%d%Y", won't fit in many localizations. Is there a default
> format for date without time that I should reference or should I just add
> such the format for the sums setting to each lang file?
>
> Tom Keffer schrieb am Freitag, 10. März 2023 um 22:18:12 UTC+1:
>
>> Yes, the query is not as optimal as it could be. It's returning the right
>> date, but the time at which maximum rainfall was achieved, rather than
>> midnight.
>>
>> You can solve your problem by applying a formatting. For example,
>>
>> *$week.rain.maxsumtime.format("%A"), $month.rain.maxsumtime("%m/%d/%Y),
>> ...*
>>
>>
>> The formatting is from Python's strftime() function
>> 
>> .
>>
>> On Fri, Mar 10, 2023 at 6:03 AM michael.k...@gmx.at 
>> wrote:
>>
>>> When I calculate "maxsum" as the maximum daily rain sum per
>>> week/month/year/alltime, I am a bit confused by the output when it comes to
>>> formatting the date/time for the value.
>>>
>>> For me, having a time for a maximum daily sum doesn't make sense in this
>>> context.
>>>
>>> So, How can I solve this? I couldn't find out so far, if I can specifiy
>>> a special time format for aggregations like "maxsum"
>>>
>>> In the template I use $week.rain.maxsumtime, $month.rain.maxsumtime,
>>> $year.rain.maxsumtime, $alltime.rain.maxsumtime. The used format makes
>>> sense for max, min, maxmin, minmax, but not for a sum.
>>>
>>> How can I make the web page show "Wednesday" for "This week",
>>> "03/08/2023" for "This month, etc, without the hh:mm:ss added?
>>>
>>> [image: 2023-03-10 14_48_03-The weather in Test - Brave.png]
>>>
>>> --
>>> 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/beb4ca00-11f5-4758-bb89-17aec6b2a956n%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/0271fd51-a86b-40e7-a242-4eb2661b166an%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/CAPq0zECkmF%2BeueD9YaSxYsxHyyb1m36iKcwAnhz2MTUwdKEyFA%40mail.gmail.com.

[weewx-user] week_start

[stefa...@gmail.com]

I've been running Weewx for years and I'm considering on changing week 
start to Monday (0) in the station section of weewx.conf. It is currently 
set to Sunday (6). Does anyone know of any implications to changing it in 
regards to reporting? 
It might seem insignificant but what day does everyone else use?

Thanks!
Stefan

-- 
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/702b5ecb-e903-4b46-a454-4181a6dc4321n%40googlegroups.com.

Re: [weewx-user] Is there a problem with the weewx-development group?

['Peter Fletcher' via weewx-user]

I reconstructed my original message and (re)submitted it to 
weewx-development via email, and it has appeared without problems. Hmmm.

On Saturday, March 11, 2023 at 1:56:16 PM UTC-5 vince wrote:

> FWIW, I had a couple messages eaten right away, most recently right before 
> my eyes after hitting send (Safari/MacOS).  Basically it accepted the post, 
> and then I saw I think 'message deleted' or the like briefly on the screen 
> in basically a fraction of a second.
>
> The last message had a small python patch in it for Tom, if that matters. 
>  I think the first message just asked a simple question.
>
> Might be worth posting a test message or two.
>
> On Saturday, March 11, 2023 at 7:17:56 AM UTC-8 Tom Keffer wrote:
>
>> It does seem to be behaving strangely --- you're not the only one who has 
>> had problems. However, there are no messages in quarantine, so I'm not sure 
>> what I can do.
>>
>> Were you posting from email, or directly to the weewx-development website?
>>
>> On Sat, Mar 11, 2023 at 5:59 AM 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> The last message in that group is from February 22, and I submitted two 
>>> messages to it a couple of days ago, which have not appeared. I was not a 
>>> member of that group until shortly before I submitted the first message, 
>>> but I would not have expected this long a moderation delay. 
>>>
>>> -- 
>>> 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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%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/04e8d267-e94e-4f6d-8134-1fc1c374bec2n%40googlegroups.com.

Re: [weewx-user] Date/time formatting for aggregation like "maxsum"

[michael.k...@gmx.at]

That was kind of what I intended to do, but while for $week using "%A" may 
be OK, using "%m/%d%Y", won't fit in many localizations. Is there a default 
format for date without time that I should reference or should I just add 
such the format for the sums setting to each lang file? 

Tom Keffer schrieb am Freitag, 10. März 2023 um 22:18:12 UTC+1:

> Yes, the query is not as optimal as it could be. It's returning the right 
> date, but the time at which maximum rainfall was achieved, rather than 
> midnight. 
>
> You can solve your problem by applying a formatting. For example,
>
> *$week.rain.maxsumtime.format("%A"), $month.rain.maxsumtime("%m/%d/%Y), 
> ...*
>
>
> The formatting is from Python's strftime() function 
> 
> .
>
> On Fri, Mar 10, 2023 at 6:03 AM michael.k...@gmx.at  
> wrote:
>
>> When I calculate "maxsum" as the maximum daily rain sum per 
>> week/month/year/alltime, I am a bit confused by the output when it comes to 
>> formatting the date/time for the value. 
>>
>> For me, having a time for a maximum daily sum doesn't make sense in this 
>> context.
>>
>> So, How can I solve this? I couldn't find out so far, if I can specifiy a 
>> special time format for aggregations like "maxsum"
>>
>> In the template I use $week.rain.maxsumtime, $month.rain.maxsumtime, 
>> $year.rain.maxsumtime, $alltime.rain.maxsumtime. The used format makes 
>> sense for max, min, maxmin, minmax, but not for a sum.
>>
>> How can I make the web page show "Wednesday" for "This week", 
>> "03/08/2023" for "This month, etc, without the hh:mm:ss added? 
>>
>> [image: 2023-03-10 14_48_03-The weather in Test - Brave.png]
>>
>> -- 
>> 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/beb4ca00-11f5-4758-bb89-17aec6b2a956n%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/0271fd51-a86b-40e7-a242-4eb2661b166an%40googlegroups.com.

Re: [weewx-user] Is there a problem with the weewx-development group?

[vince]

FWIW, I had a couple messages eaten right away, most recently right before 
my eyes after hitting send (Safari/MacOS).  Basically it accepted the post, 
and then I saw I think 'message deleted' or the like briefly on the screen 
in basically a fraction of a second.

The last message had a small python patch in it for Tom, if that matters. 
 I think the first message just asked a simple question.

Might be worth posting a test message or two.

On Saturday, March 11, 2023 at 7:17:56 AM UTC-8 Tom Keffer wrote:

> It does seem to be behaving strangely --- you're not the only one who has 
> had problems. However, there are no messages in quarantine, so I'm not sure 
> what I can do.
>
> Were you posting from email, or directly to the weewx-development website?
>
> On Sat, Mar 11, 2023 at 5:59 AM 'Peter Fletcher' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> The last message in that group is from February 22, and I submitted two 
>> messages to it a couple of days ago, which have not appeared. I was not a 
>> member of that group until shortly before I submitted the first message, 
>> but I would not have expected this long a moderation delay. 
>>
>> -- 
>> 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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%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/33f3bf41-4248-4ad1-a0f7-452899d92c25n%40googlegroups.com.

Re: [weewx-user] wee_import - dateTime not converting/importing properly

[William]

Thanks Ranier to you and Gary both for the replies. I was fairly sure I 
tried dropping the unix_epoch unit last night and got the same result, but 
just tried it again to confirm. My data originated from the old 
AmbientWeather Virtual Weather Station software that conveniently dumped 
the data to an easily-readable CSV that I could ingest into a database, and 
the CSV files I'm using for wee_import are simply a dump from this SQL 
database back into CSV format. My hopes are to eliminate this older, 
no-longer-supported software and Windows altogether (and my scripts to get 
this data into a database), and go with a Linux-supported software that is 
continued to be routinely updated, like weewx.

Here's the header and two first rows of data for 2011-05-06 at 09:57 and 
09:58.

"RecDate","WindDir","WindSpeed","WindGust","IndoorHumidity","OutdoorHumidity","IndoorTemperature","OutdoorTemperature","BarometricPressure","TotalRain","CH1Temperature","CH1Humidity","CH2Temperature","CH2Humidity","CH3Temperature","CH3Humidity","Evapotranspiration","UVindex","SolarRadiation","WindChill","IndoorHeatIndex","OutdoorHeatIndex","DewPoint","SeaLevelPressure","PressureAltitude","CloudBase","AirDensity","VirtualTemperature","VaporPressure","WindDirRate","WindSpeedRate","WindGustRate","IndoorHumidityRate","OutdoorHumidityRate","IndoorTemperatureRate","OutdoorTemperatureRate","BarometricPressureRate","TotalRainRate","CH1TemperatureRate","CH1HumidityRate","CH2TemperatureRate","CH2HumidityRate","CH3TemperatureRate","CH3HumidityRate","EvapotranspirationRate","UVindexRate","SolarRadiationRate","WindChillRate","IndoorHeatIndexRate","OutdoorHeatIndexRate","DewPointRate","SeaLevelPressureRate","RainDaily","RainHourly","Last24HrRain","RainRate","WindRunDaily","DegDaysHeatingDaily","DegDaysCoolingDaily","MoonPhase","MonthlyRain","DegDaysHeatingMonthly","DegDaysCoolingMonthly","WindRunMonthly","DegDaysHeatingYearly","DegDaysCoolingYearly","WindRunYearly"
"201105060957","0.000","0.000","0.000","38.000","73.000","74.500","49.600","30.009","0.010","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","5.000","49.600","74.270","52.921","41.313","30.009","-82.216","2071.683","-708.443","51.277","0.261","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.100","0.000","0.100","0.096","0.000","0.010","0.000","0.000","0.000","0.000","0.011","0.000","3.094","0.010","0.011","0.000","0.000","0.011","0.000","0.000"
"201105060958","0.000","0.000","0.000","38.000","73.000","74.500","49.600","30.012","0.010","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","5.000","49.600","74.270","52.921","41.313","30.012","-84.984","2071.683","-711.878","51.277","0.261","0.000","0.000","0.000","0.000","0.000","0.000","0.098","0.003","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.000","0.098","0.000","0.098","0.094","0.003","0.010","0.000","0.000","0.000","0.000","0.021","0.000","3.095","0.010","0.021","0.000","0.000","0.021","0.000","0.000"

MySQL (technically MariaDB) wraps all the fields in quotes, and tried 
wee_import both with and without them just to see if that made a 
difference. Unfortunately it did not.

Here's the full output from a wee_import dry run:

Using WeeWX configuration file /etc/weewx/weewx.conf
Starting wee_import...
A CSV import from source file '/home/william/wximport/2011_sample.csv' has 
been requested.
Using database binding 'wx_binding', which is bound to database 'weewx'
Destination table 'archive' unit system is '0x01' (US).
Missing derived observations will be calculated.
This is a dry run, imported data will not be saved to archive.
Starting dry run import ...
2 records identified for import.
Unique records processed: 2; Last timestamp: 8342-10-07 16:55:58 EDT 
(201105060958)
Finished dry run import
2 records were processed and 2 unique records would have been imported.

Thanks again!

On Saturday, March 11, 2023 at 6:01:30 AM UTC-5 Rainer Lang wrote:

> try 
>
> raw_datetime_format = %Y%m%d%H%M (that you already have)
>
> and in the field map just
>
> datetime = RecDate
>
> assuming RecDate is the header name of the date/time - drop the unix_epoch 
> addition
>
> if it still doesn't work, please provide the header line and the complete 
> first 2 lines of your import file
> On 11.03.2023 11:37, William wrote:
>
> Hi,
>
> I'm trying to import historical data into my new weewx installation. 
> Following the documentation and the sample import config, I can't seem to 
> get the date and time to parse correctly. I'm using weewx version 4.10.2 
> and wee_import version 0.7, as both were pulled down through the apt 
> package repository today.
>
> In my archive data, my date and time are stored in a RecDate field and 
> uses the format mmddHHMM. Example: 201105060957 would be more 
> appropriately readable as 2011-05-06 09:57.
>
> In the import configuration file I have 

[weewx-user] Re: Increasing image size within Seasons skin

['Michael Waldor' via weewx-user]

I've digged a little bit within source code of weewx - especially 
bin/weewx/imagegenerator.py

My goal is to shift the timeline by an offset so that I can render data 
from the "future" (from the DWD forecast). And to my surprise it's really 
simple to introduce the new option time_offset by adding only one line of 
code into imagegenerator.py
...
# Calculate a suitable min, max time for the requested time.

plotgen_ts = plotgen_ts + int(plot_options.get('time_offset', 0))

minstamp, maxstamp, timeinc = weeplot.utilities.scaletime(
plotgen_ts - int(plot_options.get('time_length', 86400)), 
plotgen_ts)
x_domain = weeutil.weeutil.TimeSpan(minstamp, maxstamp)
...
Within skin.conf I've added this "new" option time_offset = 259200 (3 
days), and I get the intended shift of the timeline by 3 days (see appended 
image).

The only disadvantage is that the timestamp printed below the image is 
shifted, too. But I think that is by design (same for wee_report with 
timestamp option).

My suggestion: Please include my small change within the next release of 
weewx.

Regards, Michael


Michael Waldor schrieb am Mittwoch, 8. März 2023 um 16:45:07 UTC+1:

> I've done more experiments w.r.t. time_enght - if I increase its value by 
> 1s from the default 27h I get an imagecoverring 48h (instead of 27h plus 
> 1s). Thus the value 97200 is kind of magic to deliver the expected 27h, but 
> it's not possible to increase the value even a little bit. See my appended 
> picture with time_length = 97201.
>
> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 15:46:06 UTC+1:
>
>> Another experiment with the (new) DWD SQlite database - sadly failing:
>>
>> From weewx customization guide I've learned that one might use (simple 
>> SQL) expressions to calculate new data within image generation. I gave it a 
>> try to calculate the windChill from the available SQL data like
>> [[[daytempfeel]]]
>> windchill
>> heatindex
>> forecast_windchill
>> data_type = windchillMetric(outTemp, windSpeed)
>> data_binding = dwd_binding
>> label = ' '
>> color = red
>> That stopped the image generator from further processing. Is this somehow 
>> possible?
>> Michael Waldor schrieb am Mittwoch, 8. März 2023 um 14:01:05 UTC+1:
>>
>>> Thanks for that hint - currently I'm still experimenting with this new 
>>> functionality.
>>>
>>> In the meantime I could resolve my problem with seasons.css - it was a 
>>> problem with caching within firefox. Even after deletion of 
>>> /var/www/htmp/weew/seasons.css firefox did render it after reload/refresh. 
>>> But when new images have been generated the missing seasons.css become 
>>> obvious, and a new seasons.css will be used. Thus one problem solved!
>>>
>>>
>>> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:50:40 UTC+1:
>>>
 I do the image size change at the top level, so that all images are the 
 same size.  I am not sure what happens if only one image is larger.

 I tested with Firefox (windows x64) and Apache server.

 Use F12 and inspect where the size directive is coming from, if you 
 feel brave.

 On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:

>
> Thanks for your quich reply. Changing the image size works fine in 
> skin.conf, but modifing seasons.css (for testing purpose at 
> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
> within firefox dspite reload?
>
> This is my current (testing) status within skin.conf - image sizes 
> currently intentionally commented:
>
> [[[daytempdew]]]   
>  
> # image_width = 600   
>   
> #image_height = 180   
>  
> outTemp   
>  
> data_type = outTemp  
> data_binding = wx_binding
> dewpoint  
> data_type = dewpoint  
> data_binding = wx_binding 
> forecast_outTemp 
> data_type = outTemp  
> label = ' '   
>   
> data_binding = dwd_binding
> color = blue   
>
> forecast_dewpoint 
> data_type = dewpoint  
> label = ' ' 
> data_binding = dwd_binding 
> color = red   
>   

Re: [weewx-user] Is there a problem with the weewx-development group?

[Tom Keffer]

It does seem to be behaving strangely --- you're not the only one who has
had problems. However, there are no messages in quarantine, so I'm not sure
what I can do.

Were you posting from email, or directly to the weewx-development website?

On Sat, Mar 11, 2023 at 5:59 AM 'Peter Fletcher' via weewx-user <
weewx-user@googlegroups.com> wrote:

> The last message in that group is from February 22, and I submitted two
> messages to it a couple of days ago, which have not appeared. I was not a
> member of that group until shortly before I submitted the first message,
> but I would not have expected this long a moderation delay.
>
> --
> 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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%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/CAPq0zEBdaEz5HZARHEOMmM6_9FcWzLu1OP4Cr9Z%3D45A%3DiMK37w%40mail.gmail.com.

Re: [weewx-user] wee_import

[Rainer Lang]

can you provide your .conf file and the first three lines of the csv 
file (header + 2 data lines) ?

On 11.03.2023 15:33, Willi Dennerlohr wrote:

unfortunately no success

Am Sa., 11. März 2023 um 14:55 Uhr schrieb Rainer Lang 
:


convert " , " into "," (without "") e.g. by using find and replace
in Microsoft Excel  - and save as a text file
On 11.03.2023 14:51, Willi Dennerlohr wrote:

The csv-import does not work:
Type-Error: "delimitter" must be a 1-character string.
In the conv - file und csv - file is the delimitter a " , ".
What can I do?
-- 
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/9b2690bc-593b-4cee-b438-00b551e50728n%40googlegroups.com

.



-- 
You received this message because you are subscribed to a topic in

the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/weewx-user/YK090sHaud8/unsubscribe.
To unsubscribe from this group and all its topics, 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/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.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/CALo2f9B4qBghh4akwsJmEp1RnfdGTqoVo6zaiBadLFdWRtxFdg%40mail.gmail.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/b4d0ea07-2855-fd40-abc9-28ca60d79013%40gmail.com.

Re: [weewx-user] wee_import

[Willi Dennerlohr]

unfortunately no success

Am Sa., 11. März 2023 um 14:55 Uhr schrieb Rainer Lang <
lang.rai...@gmail.com>:

> convert " , " into "," (without "") e.g. by using find and replace in
> Microsoft Excel  - and save as a text file
> On 11.03.2023 14:51, Willi Dennerlohr wrote:
>
> The csv-import does not work:
> Type-Error: "delimitter" must be a 1-character string.
> In the conv - file und csv - file is the delimitter a " , ".
> What can I do?
> --
> 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/9b2690bc-593b-4cee-b438-00b551e50728n%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/YK090sHaud8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.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/CALo2f9B4qBghh4akwsJmEp1RnfdGTqoVo6zaiBadLFdWRtxFdg%40mail.gmail.com.

[weewx-user] Is there a problem with the weewx-development group?

['Peter Fletcher' via weewx-user]

The last message in that group is from February 22, and I submitted two 
messages to it a couple of days ago, which have not appeared. I was not a 
member of that group until shortly before I submitted the first message, 
but I would not have expected this long a moderation delay.

-- 
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/e8333f01-42a0-49e2-8ca2-d01ee64eaab3n%40googlegroups.com.

Re: [weewx-user] wee_import

[Rainer Lang]

convert " , " into "," (without "") e.g. by using find and replace in 
Microsoft Excel  - and save as a text file

On 11.03.2023 14:51, Willi Dennerlohr wrote:

The csv-import does not work:
Type-Error: "delimitter" must be a 1-character string.
In the conv - file und csv - file is the delimitter a " , ".
What can I do?
--
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/9b2690bc-593b-4cee-b438-00b551e50728n%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/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.com.

[weewx-user] wee_import

[Willi Dennerlohr]

The csv-import does not work:
Type-Error: "delimitter" must be a 1-character string.
In the conv - file und csv - file is the delimitter a " , ".
What can I do?

-- 
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/9b2690bc-593b-4cee-b438-00b551e50728n%40googlegroups.com.
# EXAMPLE CONFIGURATION FILE FOR IMPORTING FROM CSV FILES
#
# Copyright (c) 2009-2022 Tom Keffer  and Gary Roderick.
# See the file LICENSE.txt for your rights.

##

# Specify the source. Available options are:
#   CSV - import obs from a single CSV format file
#   WU - import obs from a Weather Underground PWS history
#   Cumulus - import obs from a one or more Cumulus monthly log files
#   WD - import obs from a one or more WD monthly log files
# Format is:
#   source = (CSV | WU | Cumulus)
source = CSV

##

[CSV]
# Parameters used when importing from a CSV file

# Path and name of our CSV source file. Format is:
#   file = full path and filename
file = /var/tmp/data/data.csv

# The character used to separate fields. Format is:
#   delimiter = 
# Default is , (comma).
delimiter = ,

# Specify the character used as the decimal point. The character
# must be enclosed in quotes.
# Format is:
#   decimal = '.' (dot)
#   or
#   decimal = ',' (comma)
decimal = '.'

# If there is no mapped interval field how will the interval field be
# determined for the imported records. Available options are:
#   derive - Derive the interval field from the timestamp of successive
#records. This setting is best used when there are no missing
#records from period being imported. Missing records will
#cause the interval field to be incorrectly calculated for some
#records.
#   conf   - Use the interval setting from weewx.conf. This setting is
#best used if the records to be imported have been produced by
#WeeWX or some other means with the same archive interval as
#set in weewx.conf on this machine.
#   x  - Use a fixed interval of 'x' minutes for every record where 'x'
#is a number. This setting is best used if the records to be
#imported are equally spaced in time but there are some missing
#records.
#
# Note: If there is a mapped interval field then this setting will be
#   ignored.
# Format is:
#   interval = (derive | conf | x)
interval = derive

# Should the [StdQC] max/min limits in weewx.conf be applied to the
# imported data. This may be useful if the source has extreme values that
# are clearly incorrect for some observations. Available options are:
#   True  - weewx.conf [StdQC] max/min limits are applied.
#   False - weewx.conf [StdQC] max/min limits are not applied.
# Format is:
#   qc = (True | False)
qc = True

# Should any missing derived observations be calculated from the imported
# data if possible. Available options are:
#   True  - Any missing derived observations are calculated.
#   False - Any missing derived observations are not calculated.
# Format is:
#   calc_missing = (True | False)
calc_missing = True

# Specify how imported data fields that contain invalid data (eg a numeric
# field containing non-numeric data) are handled. Available options are:
#   True  - The invalid data is ignored, the WeeWX target field is set to
#   None and the import continues.
#   False - The import is halted.
# Format is:
#   ignore_invalid_data = (True | False)
# Default is True.
ignore_invalid_data = True

# Imported records are written to archive in transactions of tranche
# records at a time. Increase for faster throughput, decrease to reduce
# memory requirements. Format is:
#   tranche = x
# where x is an integer
tranche = 250

# Specify whether a UV sensor was used to produce any UV observations.
# Available options are:
#   True  - UV sensor was used and UV data will be imported.
#   False - UV sensor was not used and any UV data will not be imported.
#   UV fields will be set to None/NULL.
# For a CSV import UV_sensor should be set to False if a UV sensor was
# NOT present when the import data was created. Otherwise it may be set to
# True or omitted. Format is:
#   UV_sensor = (True | False)
UV_sensor = True

# Specify whether a solar radiation sensor was used to produce any solar
# 

[weewx-user] Re: wee_import - dateTime not converting/importing properly

[gjr80]

As you have confirmed python will quite happily parse a numeric date-time 
given a suitable format string. In this case the problem is within 
wee_import itself; wee_import assumes that a numeric date-time field is a 
unix epoch timestamp and uses the raw date-time data as is (WeeWX records 
date-time data as unix epoch timestamps). Ultimately when WeeWX tries to 
interpret this raw data as a unix epoch timestamp the result is a nonsense 
date-time well into the future.

This will need a change to wee_import, let me think about how to best do 
this.

Gary
On Saturday, 11 March 2023 at 20:37:13 UTC+10 William wrote:

> Hi,
>
> I'm trying to import historical data into my new weewx installation. 
> Following the documentation and the sample import config, I can't seem to 
> get the date and time to parse correctly. I'm using weewx version 4.10.2 
> and wee_import version 0.7, as both were pulled down through the apt 
> package repository today.
>
> In my archive data, my date and time are stored in a RecDate field and 
> uses the format mmddHHMM. Example: 201105060957 would be more 
> appropriately readable as 2011-05-06 09:57.
>
> In the import configuration file I have raw_datetime_format = %Y%m%d%H%M, 
> and in the FieldMap stanza, dateTime = RecDate, unix_epoch.
>
> When I do a dry run on a single record, it shows a wild date (year 8342!) 
> with the message: 
>
> Unique records processed: 1; Last timestamp: 8342-10-07 16:55:57 EDT 
> (201105060957)
>
> When I run it on a different data set it sees 202303110321 as timestamp: 
> 8380-09-24 00:25:21 EDT
>
> Am I missing something in the config? I'm fairly certain the Python 
> strptime format is correct, and have tested it in a Python script:  
> dateTime = datetime.strptime('201105060957', '%Y%m%d%H%M') 
>
> returns 
>
> datetime.datetime(2011, 5, 6, 9, 57)
> Any feedback would be greatly appreciated. Thank you! 
>

-- 
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/7e7a0d79-f4f8-45a3-9a2d-207694742112n%40googlegroups.com.

Re: [weewx-user] Where to modify the final timestamp?

[Tom Keffer]

Glad it is working for you.

That bit of code was last changed in November, 2014, so it's been that way
for a very long time.

However, it should not be so strict on requiring that the first column be
dateTime. I've filed an issue to remind myself to relax the restriction.

Issue #855 .



On Sat, Mar 11, 2023 at 1:58 AM Blaise Cacramp 
wrote:

> As in fact, Tom, the Datetime field was no longer in 1st position.
>
> I placed it properly while keeping the additional field in 2nd position
> and it still did not work, even by placing it in the last position.
>
> I have resolved it to delete it and it seems to leave, in any case, no
> error message.
> However, he no longer read the new data ...
>
> I did a wee_device --dump and (no clear memory) and there, everything
> seems to work.
> Probably your latest version is strict, because it worked before and for
> quite a long time.
>
> I would put this field in a separate and linked table
>
> Thank you Tom
> Le 10-03-23 à 19:08, Tom Keffer a écrit :
>
> I have no idea what I'm looking at there.
>
> The  requirements for the database are:
>
>1. The first column must be dateTime.
>2. The value for dateTime must never be null.
>
> Does your database satisfy these two requirements?
>
>

-- 
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/CAPq0zEDZvCXBdt2uGR0mPoCaM3XQMU9K3OKeHSPcUoKhLL3%3DCA%40mail.gmail.com.

Re: [weewx-user] wee_import - dateTime not converting/importing properly

[Rainer Lang]

try

raw_datetime_format = %Y%m%d%H%M (that you already have)

and in the field map just

datetime = RecDate

assuming RecDate is the header name of the date/time - drop the 
unix_epoch addition


if it still doesn't work, please provide the header line and the 
complete first 2 lines of your import file


On 11.03.2023 11:37, William wrote:

Hi,

I'm trying to import historical data into my new weewx installation. 
Following the documentation and the sample import config, I can't seem 
to get the date and time to parse correctly. I'm using weewx version 
4.10.2 and wee_import version 0.7, as both were pulled down through 
the apt package repository today.


In my archive data, my date and time are stored in a RecDate field and 
uses the format mmddHHMM. Example: 201105060957 would be more 
appropriately readable as 2011-05-06 09:57.


In the import configuration file I have raw_datetime_format = 
%Y%m%d%H%M, and in the FieldMap stanza, dateTime = RecDate, unix_epoch.


When I do a dry run on a single record, it shows a wild date (year 
8342!) with the message:


Unique records processed: 1; Last timestamp: 8342-10-07 16:55:57 EDT 
(201105060957)


When I run it on a different data set it sees 202303110321 as 
timestamp: 8380-09-24 00:25:21 EDT


Am I missing something in the config? I'm fairly certain the Python 
strptime format is correct, and have tested it in a Python script:

dateTime = datetime.strptime('201105060957', '%Y%m%d%H%M')

returns
datetime.datetime(2011, 5, 6, 9, 57)
Any feedback would be greatly appreciated. Thank you!
--
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/42a18d84-9140-42c1-9172-c417f42659cfn%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/41524a5f-a2f7-2a26-9857-1bcb8f58b459%40gmail.com.

[weewx-user] wee_import - dateTime not converting/importing properly

[William]

Hi,

I'm trying to import historical data into my new weewx installation. 
Following the documentation and the sample import config, I can't seem to 
get the date and time to parse correctly. I'm using weewx version 4.10.2 
and wee_import version 0.7, as both were pulled down through the apt 
package repository today.

In my archive data, my date and time are stored in a RecDate field and uses 
the format mmddHHMM. Example: 201105060957 would be more appropriately 
readable as 2011-05-06 09:57.

In the import configuration file I have raw_datetime_format = %Y%m%d%H%M, 
and in the FieldMap stanza, dateTime = RecDate, unix_epoch.

When I do a dry run on a single record, it shows a wild date (year 8342!) 
with the message: 

Unique records processed: 1; Last timestamp: 8342-10-07 16:55:57 EDT 
(201105060957)

When I run it on a different data set it sees 202303110321 as timestamp: 
8380-09-24 00:25:21 EDT

Am I missing something in the config? I'm fairly certain the Python 
strptime format is correct, and have tested it in a Python script:  
dateTime = datetime.strptime('201105060957', '%Y%m%d%H%M') 

returns 

datetime.datetime(2011, 5, 6, 9, 57)
Any feedback would be greatly appreciated. Thank you! 

-- 
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/42a18d84-9140-42c1-9172-c417f42659cfn%40googlegroups.com.

Re: [weewx-user] Where to modify the final timestamp?

[Blaise Cacramp]

As in fact, Tom, the Datetime field was no longer in 1st position.

I placed it properly while keeping the additional field in 2nd position 
and it still did not work, even by placing it in the last position.


I have resolved it to delete it and it seems to leave, in any case, no 
error message.

However, he no longer read the new data ...

I did a wee_device --dump and (no clear memory) and there, everything 
seems to work.
Probably your latest version is strict, because it worked before and for 
quite a long time.


I would put this field in a separate and linked table

Thank you Tom

Le 10-03-23 à 19:08, Tom Keffer a écrit :

I have no idea what I'm looking at there.

The requirements for the database are:

 1. The first column must be dateTime.
 2. The value for dateTime must never be null.

Does your database satisfy these two requirements?


--
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/70dcf95d-d949-0ef9-6453-0cd668bffaee%40gmail.com.