Sunrise/Sunset times off on Vantage Pro 2

100 views
Skip to first unread message

Constantine Samaklis

unread,
Jun 29, 2020, 9:16:33 PM6/29/20
to weewx-user
Wondering if anyone is having the same issue. In the last 3-4 days my Vantage pro is showing the wrong sunrise and sunset times. I am in NY and the console is set to EST daylight savings and the current time value is displayed correctly. 

For sunset I get: 1593478080, which is 8:48PM EST and for sunrise I get: 1593424080 which is 5:48am EST.

These timings are off by 20+ minutes. Not sure if this is something that anyone else is experiencing. 

Dave Webb KB1PVH

unread,
Jun 29, 2020, 9:19:43 PM6/29/20
to weewx...@googlegroups.com
I'm in Central MA and have these times. 

Sunrise:05:13
Sunset:20:27

Dave-KB1PVH


Sent from my Galaxy S9

--
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/bc84ce53-f40e-4e05-bed7-99a3a7acb2eao%40googlegroups.com.

gjr80

unread,
Jun 29, 2020, 10:23:36 PM6/29/20
to weewx-user
Hi,

I think we need to sort the apples from the oranges and bananas. Exactly what are you showing us? Is that the sunrise/sunset times as displayed on the console or as displayed in loop packet/archive record or as returned by a tag in a report? What latitude/longitude do you have set in your console and in weewx.conf? Do you have pyephem installed for the version of python that WeeWX is being run under?

Sorry for the questions, but it's a bit like the 'pressures'; there are a number of moving parts to this and unless you know exactly what is being looked at it is hard to give a meaningful answer.

Gary

Constantine Samaklis

unread,
Jun 30, 2020, 6:19:21 AM6/30/20
to weewx-user
My bad, I should have been more thorough with details. I was under the impression that the sunrise/sunset times were provided directly by the Davis console and not calculated.

The values I am getting are coming from the LOOP when running weewxd

LOOP:   2020-06-30 06:07:56 EDT (1593511676) altimeter: 29.887106231687923, barometer: 29.88, cloudbase: 1238.2237428350452, consBatteryVoltage: 3.75, dateTime: 1593511676, dayET: 0.0, dayRain: 0.0, dewpoint: 64.5434155315258, extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, extraAlarm8: 0, forecastIcon: 6, forecastRule: 45, heatindex: 69.6, inDewpoint: 45.1326136300073, inHumidity: 53.0, insideAlarm: 0, inTemp: 62.5, leafWet4: 0.0, monthET: 0.0, monthRain: 1.89, outHumidity: 84.0, outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 69.6, pressure: 29.788405301826174, rain: 0.0, rainAlarm: 0, rainRate: 0.0, soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0, stormRain: 0.0, sunrise: 1593510480.0, sunset: 1593564480.0, txBatteryStatus: 0, usUnits: 1, windchill: 69.6, windDir: None, windGust: 0.0, windGustDir: None, windSpeed: 0.0, windSpeed10: 1.0, yearET: 0.0, yearRain: 14.08

I do have the following version of ephem: python3-ephem                        3.7.6.0-7+b1 

Weewx is running on Python 3.7 

    # Latitude and longitude in decimal degrees
    latitude = 40.624573
    longitude = -74.012931

gjr80

unread,
Jun 30, 2020, 6:44:53 AM6/30/20
to weewx-user
No problems, it's just that sunrise/sunset can come from up to three different sources and you need to to know which source is the problem in order to troubleshoot.

You are right that the sunrise/sunset in loop packets comes from the console.  So in this case pyephem does not come into play nor does the lat/long settings in weewx.conf. You need to check/set the lat/long settings in your console, either via the console buttons or through use of the wee_device utility (note the if using wee_device you need to stop WeeWX first). From memory the console (via buttons or wee_device) accepts decimal degrees with a max resolution of 0.1 degree. Not sure a 0.1 degree resolution should result in an inaccuracy of 20+ minutes though. 

Gary

Constantine Samaklis

unread,
Jun 30, 2020, 7:03:37 AM6/30/20
to weewx-user
I did what you suggested (settings where fine to begin with) but still getting 20min discrepancies which are not explained by the loss of accuracy on the lon/lat.

Wondering what to try next.

gjr80

unread,
Jun 30, 2020, 8:04:04 AM6/30/20
to weewx-user
Not much else to check, timezone and daylight saving could affect it but you would expect to see variations of an hour (or perhaps 30 minutes if you are in a weird timezone).

Out of interest I just checked the loop sunrise and sunset values for my console. Sunrise according to the console is 7:00:48am and dateandtime.com and pyephem both say it is 6:38am. Sunset is a little better, according to the console it is 5:08:00pm and dateandtime.com and pyephem both agree it is 5:05pm. So it sounds like it could be a case of the console not being that accurate. Must admit I have never ever looked at, much less used, the console figures, I always use the pyephem figures and have found them to always be within a few seconds.

Gary

Jacques Terrettaz

unread,
Jun 30, 2020, 8:47:25 AM6/30/20
to weewx-user
HI,

I checked with my Davis station and I am observing exactly the same kind of differences. I think the problem is coming from the vantage weewx driver :

Here are my data concerning sunrise :
  • the console displays 05:46 for sunrise. This is correct
  • the raw loop data for sunrise, as received by Weewx , is 546 
  • weewx vantage driver is converting the raw loop data into seconds using this function 
    'sunrise'         : lambda p, k: 3600 * (p[k] / 100) + 60 * (p[k] % 100),
     giving :  3600 * (546/100) + 60 * 46 = 22416.   This is wrong, it should be 3600 * (500/100) + 60 * 46 = 20760
Should the right formulas be :
'sunrise'         : lambda p, k: 3600 * (p[k] // 100) + 60 * (p[k] % 100),
'sunset'          : lambda p, k: 3600 * (p[k] // 100) + 60 * (p[k] % 100),


?

gjr80

unread,
Jun 30, 2020, 8:55:52 AM6/30/20
to weewx-user
Ah, well spotted. This will be a python2/python3 issue. In python 2 / is integer division if both operands are integers. But in python3 / is floating point division irrespective of the operands. So the vantage driver would have worked correctly for WeeWX v3.x as well as for v4.x under python2. WeeWX v4.x under python3 will exhibit the incorrect behaviour. Guess a change is in order.

Gary

gjr80

unread,
Jun 30, 2020, 9:12:52 AM6/30/20
to weewx-user
Fixed at commit e8a5015.

Gary

gjr80

unread,
Jul 1, 2020, 1:20:41 AM7/1/20
to weewx-user
Just to close this off I installed the updated vantage driver on my system and sunrise/sunset from the console is spot on today. If the anomaly bothers you and you can't wait for 4.1.2 to be released you can download the patched vantage driver here. Just use

to download to /var/tmp and then copy in place of the existing driver (/home/weewx/bin/weewx/drivers/vantage.py or /usr/share/weewx/weewx/drivers/vantage.py) and restart WeeWX. You will need to run WeeWX directly and observer the sunrise/sunset values in the loop packets or use some other means to view the loop data as WeeWX does not normally display/use the console provided sunrise/sunset times.

Gary

Constantine Samaklis

unread,
Jul 1, 2020, 6:52:48 AM7/1/20
to weewx...@googlegroups.com
Thanks Gary. I have an application that reads the console values which are pushed to a Mosquitto MQTT server in real time so this will address the issue until the update is out. 

--
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/5IZfZge3RxU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/672bf2e7-4403-47d9-8bef-5a763ae618f1o%40googlegroups.com.

Constantine Samaklis

unread,
Jul 1, 2020, 7:59:29 AM7/1/20
to weewx-user
Thanks for taking the time and putting in the effort to troubleshoot.
Reply all
Reply to author
Forward
0 new messages