[weewx-user] Weewx Seasons Skin Monthly & Yearly Reports dropdown menus do not work

[ExprmntAl]

I noticed a few months ago that the Seasons Skin dropdown menus for the 
NOAA MOnthly and Yearly reports did not work, and wondered if I had broken 
something in Weewx along the way, but I just did a fresh install of Weewx a 
few days ago and noticed that the dropdown menus for the NOAA Monthly and 
Yearly reports still did not work properly in the Chromium Browser in 
Raspberry Pi OS (Buster).  It seems like the address for the files has some 
extra text in it highlighted below:

file:///var/www/html/weewx/tabular.html?report=NOAA/NOAA-2020.txt

If I remove the highlighted text, the link correctly pulls up the file.  
Has anyone else noticed this?  Does the Seasons Skin Index.html file need 
to be modified to correct this or is there a more appropriate way?

-- 
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/5f3da712-da28-4a85-88b8-f8dd2ee42d97n%40googlegroups.com.

Re: [weewx-user] Re: Belchertown: earthquake miles vs km's

[Colin Larsen]

Arend

Great call sir! In fact even though I use all metric units with my station
that unit was not set at all. Added group_distance = km to the Belchertown
skin and that has solved the problem

Many thanks!

Regards and best to you.
Colin

On Sun, 27 Dec 2020 at 01:07, Arend  wrote:

> Hi Colin,
>
> Could you please check in weewx.conf if your setting for group_distance is
> set to km? Like this:
>
> [[Defaults]]
> [[[Units]]]
> # The following section sets what unit to use for each unit
> group.
> # NB: The unit is always in the singular. I.e.,
> 'mile_per_hour',
> # NOT 'miles_per_hour'
> Groups
> group_altitude = meter# Options are 'foot' or 'meter'
> group_degree_day = degree_C_day# Options are
> 'degree_F_day' or 'degree_C_day'
> *group_distance = km# Options are 'mile' or 'km'*
> group_pressure = hPa# Options are 'inHg', 'mmHg',
> 'mbar', or 'hPa'
> group_rain = mm# Options are 'inch', 'cm', or 'mm'
> group_rainrate = mm_per_hour# Options are
> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
> group_speed = km_per_hour# Options are
> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
> group_speed2 = km_per_hour2# Options are
> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
> group_temperature = degree_C# Options are 'degree_F'
> or 'degree_C'
>
> Regards, Arend
> Op vrijdag 25 december 2020 om 19:40:31 UTC+1 schreef colin@gmail.com:
>
>> With the GeoNet problem I had now fixed I am also getting distances to
>> earthquake locations in miles, when the rest of my site is km
>>
>> Thanks
>> Colin
>>
>> On Fri, 25 Dec 2020, 23:35 moth...@gmail.com,  wrote:
>>
>>> yes, it works, thanks for the adjustment.
>>> Ton
>>> http://weerstationnibbixwoud.nl/
>>>
>>> Op woensdag 28 oktober 2020 om 18:45:37 UTC+1 schreef blee...@xs4all.nl:
>>>
 Hallo Arend,

 Yes, it's working!

 Just aligning the new line after #25-10.4 solved the problem, manymany
 thanks!

 Best regards, Keimpe

 Op woensdag 28 oktober 2020 om 15:31:29 UTC+1 schreef Arend:

> Hi Keimpe,
>
> I have a suspicion why it didn't work out for you. Copying your code
> from your previous post into a text editor revealed that the changes you
> made were not properly alligned. The Python language is sensitive to
> indentation. The screenshot below shows a green and red line. The second
> eqmag (#25-10.4) should have been lined up to the green line like the 
> first
> eqmag (#25-10.3). But instead it was lined up to the red line, probably
> causing an exception (error) which would result in displaying that there
> was no earthquake data available.
>
> [image: Toelichting uitlijning code.png]
>
> I have included a new version of belchertown.py that has already been
> modified with the correct changes. Could you be so kind to download this
> file and use it to replace the existing belchertown.py. If this works then
> I will use this file for a pull request.
>
>
> Mvg, Arend
>
>
> Op woensdag 28 oktober 2020 om 11:38:34 UTC+1 schreef
> blee...@xs4all.nl:
>
>> Hoi Arend,
>>
>> Thanks for your efforts.
>>
>> Now changed back to the original file and (of cours) the EQ data is
>> back, as expected in 'mijl'.
>> In the log there is no related error, the only recursive error is a
>> Failed to publish record  to WOW.
>> Undermentioned you may find the earthquake section of belchertown.py
>> with the recommended changes. Between empty lines the original lines ar
>> commented out with #25-10.1 (#date and 1 is the line-number as suggested 
>> in
>> your GitHub post), following the line copied from GitHub.
>>
>> Regards, Keimpe
>>
>>
>> """
>> Earthquake Data
>> """
>> # Only process if Earthquake data is enabled
>> if self.generator.skin_dict['Extras']['earthquake_enabled']
>> == "1":
>> earthquake_file = html_root + "/json/earthquake.json"
>> earthquake_stale_timer =
>> self.generator.skin_dict['Extras']['earthquake_stale']
>> latitude =
>> self.generator.config_dict['Station']['latitude']
>> longitude =
>> self.generator.config_dict['Station']['longitude']
>>
>> #25-10.1distance_unit =
>> converter.group_unit_dict["group_distance"]
>> distance_unit =
>> self.generator.converter.group_unit_dict["group_distance"]
>>
>> eq_distance_label =
>> self.generator.skin_dict['Units']['Labels'].get(distance_unit, "")
>> eq_distance_round =
>> self.generator.skin_dict['Un

Re: [weewx-user] Re: Sunrise and Sunset Epochs in MQTT

[gjr80]

Ok, how are the MQTT records concerned being produced? Presumably using the 
WeeWX MQTT uploader  or maybe 
something else?

Might help to get some config details, eg what station, what version of 
WeeWX, how is the MQTT uploader configured. Probably easiest to post a 
wee_debug  report. 
If posting the wee_debug report do check the report content for sensitive 
data such as usernames, passwords, addresses etc before posting. wee_debug 
does a good job at obfuscating such data but it’s not perfect.

Gary

On Sunday, 27 December 2020 at 09:28:22 UTC+10 blu...@gmail.com wrote:

> The times I see in the standard skin seem to be very accurate.  The values 
> I pull from my MQTT records never match the standard skin values; that's my 
> main confusion. 
>
> On Sat, Dec 26, 2020 at 3:25 PM gjr80  wrote:
>
>> Hi,
>>
>> Without knowing any details of your station or its config or you WeeWX 
>> config the best we can say it is should be a Unix epoch timestamp for your 
>> local sunrise and sunset time. A couple of generic troubleshooting tips; if 
>> the times are wildly in accurate then the likely culprit is an incorrect 
>> latitude or longitude setting. That setting could be in WeeWX or could be 
>> in your station hardware, again without knowing any details its impossible 
>> to say. Things to watch out for are negative and positive lat/long values, 
>> there is no standard that everyone follows. Secondly, if your times are say 
>> multiples of one hour or maybe 30 minutes out then you likely have a time 
>> setting problem somewhere; again without details its impossible to say 
>> where.
>>
>> To answer your second question it depends; however, if you are using the 
>> WeeWX Seasons skin or Standard skin then the sunrise/sunset times are for 
>> the current day.
>>
>> Gary
>>
>> On Friday, 25 December 2020 at 16:00:21 UTC+10 blu...@gmail.com wrote:
>>
>>> What do the epoch times in the sunrise and sunset MQTT topics 
>>> represent?  Based on my latest MQTT record, neither reconcile with the 
>>> times shown on the web page for sunrise and sunset?
>>>
>>> And as an aside, if I look at my webpage mid-day, does the sunrise time 
>>> shown reflect the sunrise for earlier that day, or do sunrise and sunset 
>>> times always show the next time for those events?
>>>
>>> Thanks for any help!
>>>
>>> -Kevin 
>>>
>> -- 
>> 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/3bea5494-608c-4184-8b6b-08584a80414en%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/5faff8f2-185d-40d5-8cc4-31cb3e299808n%40googlegroups.com.

[weewx-user] Re: updating missing data fields in the weewx database - can I use wee_import ?

[gjr80]

It's not really practical to use wee_import in the manner your describe. 
wee_import works by obtaining an archive record from the source and then 
inserting the archive record in the database, if a record with the same 
dateTime value already exists in the archive then the imported record is 
discarded. The only way you could use wee_import would be to export the 
records concerned from the WeeWX archive in their entirety, delete the 
records concerned from the archive, add the missing data to the exported 
data and then import the updated data back into WeeWX. It would work and 
could be automated to some extent, but there is still going to be a good 
bit of manually manipulation of the data.

You may find that you can do better by operating directly on the archive 
table with some well chosen SQL. The wee_import approach may be safest but 
I imagine will be the most labour intensive. The SQL approach may be 
quicker but also more risk of doing something bad to your, that could be 
mitigated by some testing on expendable data. You would also need to use 
wee_database to rebuild your daily summaries after using SQL to update the 
archive.

Key point in either case would be to backup your data first.

Gary
On Thursday, 24 December 2020 at 07:32:43 UTC+10 lang@googlemail.com 
wrote:

> Hi,
>
> I'm about to close gaps in my data history (due to system downtime and 
> also historical data from my pre-weewx times).
> Adding missing records is nicely described and looks rather simple and 
> straightforward.
>
> However, I don't know how to handle the update of already existing records.
> E.g. due to missing information my radiation data in the DB are missing 
> while all other sensor data are already stored.
>
> Can I use wee_import the same way I do for importing new records ?
>
> If so, what data do I have to provide ? Only the content of the 
> to-be-updated fields or the whole record (i.e. values for all fields).
>
> Or, does it not work with wee_import and I have to do it differently ?
> If so, how ?
>
> --
>
> Another question indirectly related to the import of history data.
>
> How do I display earlier years (in day, week, month, year aggregation like 
> in the current year ?) beyond the scarce reports to be chosen in the "upper 
> right corner" ?
>
> Will I have to create a sort of history skin where I can select date, 
> week, month, year and based on this selection the picture generator will 
> provide the graphics ?
> Or does some such"piece" already exist (fully, partially, ...) ?
>
> Please advise.
>
> Thanks
> Rainer
>

-- 
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/0458c50b-0cfa-4b41-bc3c-162224d4913an%40googlegroups.com.

Re: [weewx-user] Re: Sunrise and Sunset Epochs in MQTT

[Kevin Davis]

The times I see in the standard skin seem to be very accurate.  The values
I pull from my MQTT records never match the standard skin values; that's my
main confusion.

On Sat, Dec 26, 2020 at 3:25 PM gjr80  wrote:

> Hi,
>
> Without knowing any details of your station or its config or you WeeWX
> config the best we can say it is should be a Unix epoch timestamp for your
> local sunrise and sunset time. A couple of generic troubleshooting tips; if
> the times are wildly in accurate then the likely culprit is an incorrect
> latitude or longitude setting. That setting could be in WeeWX or could be
> in your station hardware, again without knowing any details its impossible
> to say. Things to watch out for are negative and positive lat/long values,
> there is no standard that everyone follows. Secondly, if your times are say
> multiples of one hour or maybe 30 minutes out then you likely have a time
> setting problem somewhere; again without details its impossible to say
> where.
>
> To answer your second question it depends; however, if you are using the
> WeeWX Seasons skin or Standard skin then the sunrise/sunset times are for
> the current day.
>
> Gary
>
> On Friday, 25 December 2020 at 16:00:21 UTC+10 blu...@gmail.com wrote:
>
>> What do the epoch times in the sunrise and sunset MQTT topics represent?
>> Based on my latest MQTT record, neither reconcile with the times shown on
>> the web page for sunrise and sunset?
>>
>> And as an aside, if I look at my webpage mid-day, does the sunrise time
>> shown reflect the sunrise for earlier that day, or do sunrise and sunset
>> times always show the next time for those events?
>>
>> Thanks for any help!
>>
>> -Kevin
>>
> --
> 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/3bea5494-608c-4184-8b6b-08584a80414en%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/CAHiQ_B2a1NvidYgkVezU6Cq-9LCbYQAJ-BpHCUDKyQZuG1q8fw%40mail.gmail.com.

[weewx-user] Re: Sunrise and Sunset Epochs in MQTT

[gjr80]

Hi,

Without knowing any details of your station or its config or you WeeWX 
config the best we can say it is should be a Unix epoch timestamp for your 
local sunrise and sunset time. A couple of generic troubleshooting tips; if 
the times are wildly in accurate then the likely culprit is an incorrect 
latitude or longitude setting. That setting could be in WeeWX or could be 
in your station hardware, again without knowing any details its impossible 
to say. Things to watch out for are negative and positive lat/long values, 
there is no standard that everyone follows. Secondly, if your times are say 
multiples of one hour or maybe 30 minutes out then you likely have a time 
setting problem somewhere; again without details its impossible to say 
where.

To answer your second question it depends; however, if you are using the 
WeeWX Seasons skin or Standard skin then the sunrise/sunset times are for 
the current day.

Gary

On Friday, 25 December 2020 at 16:00:21 UTC+10 blu...@gmail.com wrote:

> What do the epoch times in the sunrise and sunset MQTT topics represent?  
> Based on my latest MQTT record, neither reconcile with the times shown on 
> the web page for sunrise and sunset?
>
> And as an aside, if I look at my webpage mid-day, does the sunrise time 
> shown reflect the sunrise for earlier that day, or do sunrise and sunset 
> times always show the next time for those events?
>
> Thanks for any help!
>
> -Kevin 
>

-- 
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/3bea5494-608c-4184-8b6b-08584a80414en%40googlegroups.com.

[weewx-user] Lost sensor contact alarm

[Manuel]

Hi. I would like weewx to send me an email when the external sensors of my 
fine offset vh 1080 station are disconnected,  the same as in alarm.py. I 
know you can since I have seen the code in the realtime.txt "if 'status' in 
packet and packet ['status'] & 0x40! = 0: return 1 return 0 " But I do not 
know how to do it. Any ideas? Thanks a lot. 

-- 
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/5300deb4-215b-4f72-84b2-2619af6aee05n%40googlegroups.com.

Re: [weewx-user] Problem after power outage

[Rich Strle]

Exactly right. This fixed my problem. Thanks for pointing me in the right 
direction.

On Thursday, December 24, 2020 at 5:58:02 PM UTC-6 tke...@gmail.com wrote:

> Classic corrupt logger memory. 
> 
>
> On Thu, Dec 24, 2020 at 3:37 PM Rich Strle  wrote:
>
>> We lost power last night and now I'm not updating. The FTP part is 
>> working, my image is processing correctly and I see the timestamp change as 
>> it should.
>>
>> I have reset my Davis Envoy but no joy. Ideas please?
>>
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.restx.StdWunderground
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.restx.StdPWSweather
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.restx: PWSweather: 
>> Posting not enabled.
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.restx.StdPWSweather
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.restx.StdCWOP
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.restx: CWOP: Posting not 
>> enabled.
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.restx.StdCWOP
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.restx.StdWOW
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.restx: WOW: Posting not 
>> enabled.
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.restx.StdWOW
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.restx.StdAWEKAS
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.restx: AWEKAS: Posting 
>> not enabled.
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.restx.StdAWEKAS
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.engine.StdPrint
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.engine.StdPrint
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Loading service 
>> weewx.engine.StdReport
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.engine: Finished 
>> loading service weewx.engine.StdReport
>> Dec 24 17:26:42 pi-weather weewx[428] INFO __main__: Starting up weewx 
>> version 4.2.0
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.engine: Clock error is 
>> -1545.78 seconds (positive is fast)
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.manager: Daily summary 
>> version is 2
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.drivers.vantage: Clock 
>> set to 2020-12-24 17:26:43 CST (1608852403)
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.engine: Using binding 
>> 'wx_binding' to database 'weewx.sdb'
>> Dec 24 17:26:42 pi-weather weewx[428] INFO weewx.manager: Starting 
>> backfill of daily summaries
>> Dec 24 17:26:42 pi-weather weewx[428] DEBUG weewx.drivers.vantage: 
>> Getting archive packets since 2020-12-24 01:50:00 CST (1608796200)
>> Dec 24 17:26:46 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Retry 
>> #0 failed
>> Dec 24 17:26:46 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Dec 24 17:26:46 pi-weather weewx[428] DEBUG weewx.drivers.vantage: 
>> Retrieving 0 page(s); starting index= 0
>> Dec 24 17:26:46 pi-weather weewx[428] INFO weewx.engine: Starting main 
>> packet loop.
>> Dec 24 17:26:50 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Retry 
>> #0 failed
>> Dec 24 17:26:50 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>> Dec 24 17:26:50 pi-weather weewx[428] DEBUG weewx.drivers.vantage: 
>> Requesting 200 LOOP packets.
>> Dec 24 17:26:50 pi-weather weewx[428] DEBUG weewx.drivers.vantage: Gentle 
>> wake up of console successful
>>
>> -- 
>> 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/9b26d540-a649-44b1-bd76-cfb0f3370530n%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

Re: [weewx-user] 4.2.0 simulator - bug & fix for configuring list of observations

[Graham Eddy]

i tried sending a pull request for [[calculations]] change - did that arrive?
i also then tried re-sending the simulator fix as a pull request but following 
the same procedure in github didn’t find a change to send - did that get 
gobbled into the other pull request somehow?
github is all strange to me...

> On 26 Dec 2020, at 11:42 pm, Tom Keffer  wrote:
> 
> Fixed in commit d9a4daa 
> 

-- 
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/948AA868-A869-437D-ADBE-4377F7BB6870%40gmail.com.

Re: [weewx-user] 4.2.0 simulator - bug & fix for configuring list of observations

[Tom Keffer]

Fixed in commit d9a4daa


Thanks, Graham!

-tk

On Fri, Dec 25, 2020 at 7:58 PM Graham Eddy  wrote:

> hello tom,
> hopefully a simple fix that can make it into 4.3.0...
>
> problem:
> weewx 4.2.0 simulator crashes when i specify the list of observations to
> include
>
> weewx.conf extract:
> (note: ‘observations = ‘ line is one line. the line break is an artifact
> of copy&paste)
>
> [GeSimulator]
> # This section is for the weewx weather station simulator
>
> # The time (in seconds) between LOOP packets.
> loop_interval = 2.5
>
> # The simulator mode can be either 'simulator' or 'generator'.
> # Real-time simulator. Sleep between each LOOP packet.
> mode = simulator
> # Generator.  Emit LOOP packets as fast as possible (useful for
> testing).
> #mode = generator
>
> # The start time. Format is -mm-ddTHH:MM. If not specified, the
> default
> # is to use the present time.
> #start = 2011-01-01T00:00
>
> # list of variables for simulator to generate.
> # note: if this is specified, only these will be produced
> # remove PM2.5 and AQI variables
> observations =
> inTemp,barometer,pressure,windSpeed,windDir,windGust,windGustDir,outHumidity,inHumidity,radiation,UV,rain,txBatteryStatus,windBatteryStatus,rainBatteryStatus,outTempBatteryStatus,inTempBatteryStatus,consBatteryVoltage,heatingVoltage,supplyVoltage,referenceVoltage,rxCheckPercent,altOutTemp,altInTemp,altPressure,altWindSpeed,altWindDir,altWindGust,altWindGustDir,altOutHumidity,altInHumidity,altRain,luminosity,solarEnergy,soilMoist1,soilMoist2,riverLevel,extraTemp1,wh40_batt,wh41_ch1_batt,wh41_ch2_batt,wh51_ch1_batt,wh51_ch2_batt,wh57_batt,ws80_batt
>
> # The driver to use:
> driver = user.gesimulator
>
>
> log extract:
>
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL weewx.engine: 
> File "/opt/weewx-4.2.0-test/bin/weewx/drivers/simulator.py", line 139, in
> __init__
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL weewx.engine: 
> self.trim_observations(stn_dict)
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL weewx.engine: 
> File "/opt/weewx-4.2.0-test/bin/weewx/drivers/simulator.py", line 144, in
> trim_observations
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL weewx.engine: 
> desired = [x.strip() for x in stn_dict['observations'].split(',')]
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL weewx.engine: 
> AttributeError: 'list' object has no attribute 'split'
> Dec 26 14:01:36 dizzy weewx-test[332] CRITICAL __main__: Unable to load
> driver: 'list' object has no attribute 'split'
>
>
> rationale:
> clearly the ‘observations =‘ line has been parsed as a list not as a
> string so split() fails
>
> suggested fix:
> weewx.drivers.simulator replace line 144 from
> desired = [x.strip() for x in stn_dict['observations'].split(
> ',')]
> to
> desired = stn_dict['observations']
> if isinstance(desired, str):
> # convert comma-separated string to list
> desired = [x.strip() for x in desired.split(',')]
>
> cheers
>
> --
> 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/419112CF-BA4B-4B03-B7E3-E07B95F04DEA%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/CAPq0zECVDp5Za-M8T6RJXwmmtDyNFhfE%2BLK38jnFvcdJzMqHkw%40mail.gmail.com.

Re: [weewx-user] Re: Belchertown: earthquake miles vs km's

[Arend]

Hi Colin,

Could you please check in weewx.conf if your setting for group_distance is 
set to km? Like this:

[[Defaults]]
[[[Units]]]
# The following section sets what unit to use for each unit 
group.
# NB: The unit is always in the singular. I.e., 'mile_per_hour',
# NOT 'miles_per_hour'
Groups
group_altitude = meter# Options are 'foot' or 'meter'
group_degree_day = degree_C_day# Options are 
'degree_F_day' or 'degree_C_day'
*group_distance = km# Options are 'mile' or 'km'*
group_pressure = hPa# Options are 'inHg', 'mmHg', 
'mbar', or 'hPa'
group_rain = mm# Options are 'inch', 'cm', or 'mm'
group_rainrate = mm_per_hour# Options are 
'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
group_speed = km_per_hour# Options are 'mile_per_hour', 
'km_per_hour', 'knot', or 'meter_per_second'
group_speed2 = km_per_hour2# Options are 
'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
group_temperature = degree_C# Options are 'degree_F' or 
'degree_C'

Regards, Arend
Op vrijdag 25 december 2020 om 19:40:31 UTC+1 schreef colin@gmail.com:

> With the GeoNet problem I had now fixed I am also getting distances to 
> earthquake locations in miles, when the rest of my site is km
>
> Thanks
> Colin
>
> On Fri, 25 Dec 2020, 23:35 moth...@gmail.com,  wrote:
>
>> yes, it works, thanks for the adjustment.
>> Ton
>> http://weerstationnibbixwoud.nl/
>>
>> Op woensdag 28 oktober 2020 om 18:45:37 UTC+1 schreef blee...@xs4all.nl:
>>
>>> Hallo Arend,
>>>
>>> Yes, it's working!
>>>
>>> Just aligning the new line after #25-10.4 solved the problem, manymany 
>>> thanks! 
>>>
>>> Best regards, Keimpe
>>>
>>> Op woensdag 28 oktober 2020 om 15:31:29 UTC+1 schreef Arend:
>>>
 Hi Keimpe,

 I have a suspicion why it didn't work out for you. Copying your code 
 from your previous post into a text editor revealed that the changes you 
 made were not properly alligned. The Python language is sensitive to 
 indentation. The screenshot below shows a green and red line. The second 
 eqmag (#25-10.4) should have been lined up to the green line like the 
 first 
 eqmag (#25-10.3). But instead it was lined up to the red line, probably 
 causing an exception (error) which would result in displaying that there 
 was no earthquake data available.

 [image: Toelichting uitlijning code.png]

 I have included a new version of belchertown.py that has already been 
 modified with the correct changes. Could you be so kind to download this 
 file and use it to replace the existing belchertown.py. If this works then 
 I will use this file for a pull request.


 Mvg, Arend


 Op woensdag 28 oktober 2020 om 11:38:34 UTC+1 schreef blee...@xs4all.nl
 :

> Hoi Arend,
>
> Thanks for your efforts.
>
> Now changed back to the original file and (of cours) the EQ data is 
> back, as expected in 'mijl'.
> In the log there is no related error, the only recursive error is a 
> Failed to publish record  to WOW.
> Undermentioned you may find the earthquake section of belchertown.py 
> with the recommended changes. Between empty lines the original lines ar 
> commented out with #25-10.1 (#date and 1 is the line-number as suggested 
> in 
> your GitHub post), following the line copied from GitHub.
>
> Regards, Keimpe
>
>  
> """
> Earthquake Data
> """
> # Only process if Earthquake data is enabled
> if self.generator.skin_dict['Extras']['earthquake_enabled'] == 
> "1":
> earthquake_file = html_root + "/json/earthquake.json"
> earthquake_stale_timer = 
> self.generator.skin_dict['Extras']['earthquake_stale']
> latitude = 
> self.generator.config_dict['Station']['latitude']
> longitude = 
> self.generator.config_dict['Station']['longitude']
>
> #25-10.1distance_unit = converter.group_unit_dict["group_distance"]
> distance_unit = 
> self.generator.converter.group_unit_dict["group_distance"]
>
> eq_distance_label = 
> self.generator.skin_dict['Units']['Labels'].get(distance_unit, "")
> eq_distance_round = 
> self.generator.skin_dict['Units']['StringFormats'].get(distance_unit, 
> "%.1f")
> earthquake_maxradiuskm = 
> self.generator.skin_dict['Extras']['earthquake_maxradiuskm']
> #Sample URL from Belchertown Weather: 
> http://earthquake.usgs.gov/fdsnws/event/1/query?limit=1&lat=42.223&lon=-72.374&maxradiuskm=1000&format=geojson&nodata=204&minmag=2
>

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

[Graham Eddy]

to reduce the problem space, maybe ignore FTP for now - just look at the 
generated files locally. if timestamps are all over the place, either new ones 
are not being attempted (skin config error) or they are failing (template 
content failure)

watching tail, sometimes many screenfulls of log are generated at once and you 
can miss big chunks. i suggest using an editor to look at the log, line by 
line, to confirm (a) it has found the report definition; (b) it is enabled and 
will attempt generating all its files; (c) any errors; (d) completion of report 
generation

> On 26 Dec 2020, at 10:13 pm, Joe  wrote:
> 
> I''m watching with TAIL and I dont see any errors. It's making the images and 
> using FTP to send as needed but the dates and times on the published HTML is 
> all over. Some says 2am, some says last night at 830pm.
> 
> The FTP files date/time are mostly Dec 26 now, but some are 25th.
> 

-- 
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/CCD3CB62-0971-4CAD-9C4D-C81E3962232D%40gmail.com.

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

[Joe]

I''m watching with TAIL and I dont see any errors. It's making the images 
and using FTP to send as needed but the dates and times on the published 
HTML is all over. Some says 2am, some says last night at 830pm.

The FTP files date/time are mostly Dec 26 now, but some are 25th.


On Saturday, December 26, 2020 at 5:09:58 AM UTC-6 graha...@gmail.com wrote:

> sounds like some files might not be generating. are the timestamps on the 
> generated files current? errors in log?
>
> On 26 Dec 2020, at 9:56 pm, Joe  wrote:
>
> Looks like its all working and accessing the davis OK.
>
> Only problem Im having now is the dates and times on the generated HTML 
> are all over the place.  Some of it is from a couple days ago, some of it 
> is last night and the mobile and smartphone HTML is not current.
>
> On Friday, December 25, 2020 at 8:35:05 PM UTC-6 Joe wrote:
>
>> Reimaged it finally and got the database conf file and such transferred 
>> over.  
>>
>> Now its catching up with all the data its been storing the past few days 
>> in the Davis and publishing the records for last few days.
>>
>> I guess it has been a few years since I have done this so its not too bad 
>> I guess.
>>
>> Hopefully I dont loose much data.  I'm still miffed why I lost 6mo of 
>> data when I restored a backup from 6 months ago but I probably just dont 
>> understand how the database is written is all.  
>>
>> Such is life! I Do appreciate, as I always do the responses from the 
>> group.  
>>
>> On Friday, December 25, 2020 at 7:31:09 PM UTC-6 vince wrote:
>>
>>> You can get old versions of weewx .deb packages at 
>>> http://weewx.com/downloads/released_versions/ if you know what version 
>>> you used to use.   Check your weewx.conf file for the version identifier 
>>> near the top.You could alternately use the 'setup.py' method to install 
>>> current weewx on your ancient os, likely using python2 that your old os 
>>> probably has as its default.
>>>
>>> But your preferred path is reflash to a current os and install current 
>>> weewx and then you're good for a long time.   You're talking 15 minutes of 
>>> work to do that.
>>>
>>> I would suggest not bothering trying a dist-upgrade from debian-7 to 
>>> debian-10, as it's going to take forever and likely will not work anyway.   
>>> Just reimage clean to current RaspiOS which is based on current debian and 
>>> get caught up once and for all.
>>>
>>> On Friday, December 25, 2020 at 4:53:02 PM UTC-8 Joe wrote:
>>>
 Really sucks I gotta completely re-image and re-set my whole PI board 
 for this.  I get used to set-forget .  I downloaded the files it needs. 
 Database. conf files etc as the online site says.

 I was hoping this program would be more backward compatible with the 
 RPI OS.

 On Friday, December 25, 2020 at 1:06:21 PM UTC-6 vince wrote:

> Yup - your os is far too ancient for the libraries the weewx dpkg is 
> built against.   That version went end-of-life in May-2018.
>
> I'd suggest you reimage with the current RaspiOS from  
> https://www.raspberrypi.org/software/operating-systems and then 
> you'll be up to date and supportable.  The weewx package works just fine 
> in 
> the current os.
>
> On Friday, December 25, 2020 at 2:35:04 AM UTC-8 Joe wrote:
>
>> That worked.  7.8
>>
>>
>> PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
>> NAME="Raspbian GNU/Linux"
>> VERSION_ID="7"
>> VERSION="7 (wheezy)"
>> ID=raspbian
>> ID_LIKE=debian
>> ANSI_COLOR="1;31"
>> HOME_URL="http://www.raspbian.org/";
>> SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
>> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";
>> root@raspberrypi:/etc# 
>>
>> On Thursday, December 24, 2020 at 11:44:26 PM UTC-6 vince wrote:
>>
>>> The current kernel version is 5.4.79 according to the release notes 
>>> at https://www.raspberrypi.org/software/operating-systems
>>>
>>> My suspicion is that you are running an ancient os version that is 
>>> too old for the current packaged version of weewx.
>>>
>>> Again, please run the following commands and provide the results.
>>>
>>>- cat /etc/debian_version
>>>- cat /etc/os-release
>>>
>>>
>>> On Thursday, December 24, 2020 at 6:26:16 PM UTC-8 Joe wrote:
>>>
 Neither of those directories exist.

 Its raspberrypi 3.18.7

 On Thursday, December 24, 2020 at 9:53:49 AM UTC-6 vince wrote:

> On Thursday, December 24, 2020 at 4:33:57 AM UTC-8 Joe wrote:
>
>> You mean to say running on the SD-CARD is bad idea?
>
>
> Not bad, but not great if the card and power aren't quality.  But 
> yes I misstyped my original reply.
>
> Re: your previous message containing " *d**pkg-deb: error: 
> archive '/var/cache/apt/archives/weewx_4.2.0-1_

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

[Graham Eddy]

sounds like some files might not be generating. are the timestamps on the 
generated files current? errors in log?

> On 26 Dec 2020, at 9:56 pm, Joe  wrote:
> 
> Looks like its all working and accessing the davis OK.
> 
> Only problem Im having now is the dates and times on the generated HTML are 
> all over the place.  Some of it is from a couple days ago, some of it is last 
> night and the mobile and smartphone HTML is not current.
> 
> On Friday, December 25, 2020 at 8:35:05 PM UTC-6 Joe wrote:
> Reimaged it finally and got the database conf file and such transferred over. 
>  
> 
> Now its catching up with all the data its been storing the past few days in 
> the Davis and publishing the records for last few days.
> 
> I guess it has been a few years since I have done this so its not too bad I 
> guess.
> 
> Hopefully I dont loose much data.  I'm still miffed why I lost 6mo of data 
> when I restored a backup from 6 months ago but I probably just dont 
> understand how the database is written is all.  
> 
> Such is life! I Do appreciate, as I always do the responses from the group.  
> 
> On Friday, December 25, 2020 at 7:31:09 PM UTC-6 vince wrote:
> You can get old versions of weewx .deb packages at 
> http://weewx.com/downloads/released_versions/ 
>  if you know what version you 
> used to use.   Check your weewx.conf file for the version identifier near the 
> top.You could alternately use the 'setup.py' method to install current 
> weewx on your ancient os, likely using python2 that your old os probably has 
> as its default.
> 
> But your preferred path is reflash to a current os and install current weewx 
> and then you're good for a long time.   You're talking 15 minutes of work to 
> do that.
> 
> I would suggest not bothering trying a dist-upgrade from debian-7 to 
> debian-10, as it's going to take forever and likely will not work anyway.   
> Just reimage clean to current RaspiOS which is based on current debian and 
> get caught up once and for all.
> 
> On Friday, December 25, 2020 at 4:53:02 PM UTC-8 Joe wrote:
> Really sucks I gotta completely re-image and re-set my whole PI board for 
> this.  I get used to set-forget .  I downloaded the files it needs. Database. 
> conf files etc as the online site says.
> 
> I was hoping this program would be more backward compatible with the RPI OS.
> 
> On Friday, December 25, 2020 at 1:06:21 PM UTC-6 vince wrote:
> Yup - your os is far too ancient for the libraries the weewx dpkg is built 
> against.   That version went end-of-life in May-2018.
> 
> I'd suggest you reimage with the current RaspiOS from  
> https://www.raspberrypi.org/software/operating-systems 
>  and then you'll be 
> up to date and supportable.  The weewx package works just fine in the current 
> os.
> 
> On Friday, December 25, 2020 at 2:35:04 AM UTC-8 Joe wrote:
> That worked.  7.8
> 
> 
> PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="7"
> VERSION="7 (wheezy)"
> ID=raspbian
> ID_LIKE=debian
> ANSI_COLOR="1;31"
> HOME_URL="http://www.raspbian.org/ "
> SUPPORT_URL="http://www.raspbian.org/RaspbianForums 
> "
> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs 
> "
> root@raspberrypi:/etc# 
> 
> On Thursday, December 24, 2020 at 11:44:26 PM UTC-6 vince wrote:
> The current kernel version is 5.4.79 according to the release notes at 
> https://www.raspberrypi.org/software/operating-systems 
> 
> 
> My suspicion is that you are running an ancient os version that is too old 
> for the current packaged version of weewx.
> 
> Again, please run the following commands and provide the results.
> cat /etc/debian_version
> cat /etc/os-release
> 
> On Thursday, December 24, 2020 at 6:26:16 PM UTC-8 Joe wrote:
> Neither of those directories exist.
> 
> Its raspberrypi 3.18.7
> 
> On Thursday, December 24, 2020 at 9:53:49 AM UTC-6 vince wrote:
> On Thursday, December 24, 2020 at 4:33:57 AM UTC-8 Joe wrote:
> You mean to say running on the SD-CARD is bad idea?
> 
> Not bad, but not great if the card and power aren't quality.  But yes I 
> misstyped my original reply.
> 
> Re: your previous message containing " dpkg-deb: error: archive 
> '/var/cache/apt/archives/weewx_4.2.0-1_all.deb' contains not understood data 
> member control.tar.xz, giving up", that's an unusual message.
> 
> What version of raspi os are you running ?
> Can we see the contents of /etc/os-release and /etc/debian_version please ?
> 
> 
> 
> -- 
> 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 
> 

[weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

[Joe]

Looks like its all working and accessing the davis OK.

Only problem Im having now is the dates and times on the generated HTML are 
all over the place.  Some of it is from a couple days ago, some of it is 
last night and the mobile and smartphone HTML is not current.

On Friday, December 25, 2020 at 8:35:05 PM UTC-6 Joe wrote:

> Reimaged it finally and got the database conf file and such transferred 
> over.  
>
> Now its catching up with all the data its been storing the past few days 
> in the Davis and publishing the records for last few days.
>
> I guess it has been a few years since I have done this so its not too bad 
> I guess.
>
> Hopefully I dont loose much data.  I'm still miffed why I lost 6mo of data 
> when I restored a backup from 6 months ago but I probably just dont 
> understand how the database is written is all.  
>
> Such is life! I Do appreciate, as I always do the responses from the 
> group.  
>
> On Friday, December 25, 2020 at 7:31:09 PM UTC-6 vince wrote:
>
>> You can get old versions of weewx .deb packages at 
>> http://weewx.com/downloads/released_versions/ if you know what version 
>> you used to use.   Check your weewx.conf file for the version identifier 
>> near the top.You could alternately use the 'setup.py' method to install 
>> current weewx on your ancient os, likely using python2 that your old os 
>> probably has as its default.
>>
>> But your preferred path is reflash to a current os and install current 
>> weewx and then you're good for a long time.   You're talking 15 minutes of 
>> work to do that.
>>
>> I would suggest not bothering trying a dist-upgrade from debian-7 to 
>> debian-10, as it's going to take forever and likely will not work anyway.   
>> Just reimage clean to current RaspiOS which is based on current debian and 
>> get caught up once and for all.
>>
>> On Friday, December 25, 2020 at 4:53:02 PM UTC-8 Joe wrote:
>>
>>> Really sucks I gotta completely re-image and re-set my whole PI board 
>>> for this.  I get used to set-forget .  I downloaded the files it needs. 
>>> Database. conf files etc as the online site says.
>>>
>>> I was hoping this program would be more backward compatible with the RPI 
>>> OS.
>>>
>>> On Friday, December 25, 2020 at 1:06:21 PM UTC-6 vince wrote:
>>>
 Yup - your os is far too ancient for the libraries the weewx dpkg is 
 built against.   That version went end-of-life in May-2018.

 I'd suggest you reimage with the current RaspiOS from  
 https://www.raspberrypi.org/software/operating-systems and then you'll 
 be up to date and supportable.  The weewx package works just fine in the 
 current os.

 On Friday, December 25, 2020 at 2:35:04 AM UTC-8 Joe wrote:

> That worked.  7.8
>
>
> PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="7"
> VERSION="7 (wheezy)"
> ID=raspbian
> ID_LIKE=debian
> ANSI_COLOR="1;31"
> HOME_URL="http://www.raspbian.org/";
> SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";
> root@raspberrypi:/etc# 
>
> On Thursday, December 24, 2020 at 11:44:26 PM UTC-6 vince wrote:
>
>> The current kernel version is 5.4.79 according to the release notes 
>> at https://www.raspberrypi.org/software/operating-systems
>>
>> My suspicion is that you are running an ancient os version that is 
>> too old for the current packaged version of weewx.
>>
>> Again, please run the following commands and provide the results.
>>
>>- cat /etc/debian_version
>>- cat /etc/os-release
>>
>>
>> On Thursday, December 24, 2020 at 6:26:16 PM UTC-8 Joe wrote:
>>
>>> Neither of those directories exist.
>>>
>>> Its raspberrypi 3.18.7
>>>
>>> On Thursday, December 24, 2020 at 9:53:49 AM UTC-6 vince wrote:
>>>
 On Thursday, December 24, 2020 at 4:33:57 AM UTC-8 Joe wrote:

> You mean to say running on the SD-CARD is bad idea?


 Not bad, but not great if the card and power aren't quality.  But 
 yes I misstyped my original reply.

 Re: your previous message containing " *d**pkg-deb: error: archive 
 '/var/cache/apt/archives/weewx_4.2.0-1_all.deb' contains not 
 understood 
 data member control.tar.xz, giving up*", that's an unusual message.

 What version of raspi os are you running ?
 Can we see the contents of /etc/os-release and /etc/debian_version 
 please ?




-- 
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/0771af19-832b-40a9-b96a-167d8f0

Re: [weewx-user] [[Calculations]] on archive record not loop packet?

[Graham Eddy]

‘push request’ created (i think… github said something about deprecated) for 
‘loop’ and/or ‘archive’
i.e. aqi=software (defaults to both bindings) or aqi=software,loop or 
aqi=software,archive or aqi=software,loop,archive

> On 22 Dec 2020, at 11:47 am, Graham Eddy  wrote:
> 
> good idea. i'll code & submit that
> 
> On Tue, 22 Dec 2020, 11:06 am Tom Keffer,  > wrote:
> Hi, Graham
> 
> Seems like a reasonable thing to do but, no, there is no way at this point. 
> Perhaps the [[Calculations]] section should be expanded to:
> 
> [StdWXCalculate]
>   [[Calculations]]
> aqi = software, record
> 
> That is, it takes an optional second positional parameter that can be one of 
> 'loop', 'record', or 'both'. The default would be 'both'.
> 

-- 
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/8DA0EB9C-18B0-4F15-9384-6F3E0BA5C595%40gmail.com.

Re: [weewx-user] Is it after sunset?

[Graham Eddy]

put a test into script to see if celestial time is in interval between now and 
now+5mins.
then either (a) generate the script, embedding the celestial time inside the 
script, or; (b) generate a file with the celestial timestamp, and your script 
reads the value from this generated file

> On 26 Dec 2020, at 5:10 pm, Robin  wrote:
> 
> I have a script that runs every five minutes, grabs an image from my webcam 
> and adds some text before it is uploaded to my website. I would like to test 
> if it is the first grab after sunset so that I can do some extra 'stuff' with 
> the image.
> 
> I am getting more and more frustrated by my lack of skill, knowledge and 
> diminishing brain power (not sure if it is advanced years or ouzo).
> 
> Please can somebody help.
> 
> 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/95f868c7-1080-4d27-8faf-9640ba580750n%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/9CE9CB37-675A-4C11-9599-D27D8487E8A1%40gmail.com.