[weewx-user] Re: weewx_wd
I came upon this because my moon info was not populating. When I tried to install pyephem there were errors that setup couldn't be found. I corrected that with pip install --upgrade setuptools Then pyephem installed fine. This was likely due to an upgrade of Mint from 18.3 to 19 I believe it was updating before that OS update, then stopped afterward. Just wanted to put this here for anyone who searches for weewx_wd moon. -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
It's seeming like that's my best option - Move the NOAA reports to a 2nd skin, then add that skin to the install.py. On Friday, August 24, 2018 at 7:11:01 PM UTC-4, gjr80 wrote: > > On Saturday, 25 August 2018 08:14:40 UTC+10, Pat wrote: >> >> >> I'm assuming if this is only affecting the highchartsDay class - and not >> the others - that there's a way to make the day charts play nice with the >> other SLEs? >> > > No, it will affect the others, week will be the same, month and year will > likely be the same though there could be some subtleties going on as the > period increases to match the SummaryBy period. > > Thinking some more you could check timespan.stop against the last good > record in the db and only proceed with the SLE if they match. You could > also probably do something to turn off 'highcharts plots' just for the > SummaryBy reports, so rather than from [Extras] do it as an option under > the [[]] stanzas. I think both are pretty kludgey though. > > Don't discount a second skin so quickly, it is simple to implement and has > the advantage of eliminating a whole pile of db queries. When we put > together WeeWX-WD we had 8 reports that used a wide variety of data. Some > reports were current point in time and others were full of month, year and > alltime aggregates. We split that into 3 skins, it provided a significant > improvement in generation time because whole lot of unnecessary db queries > no longer occurred. Lazy evaluation of SLE results can improve execution > time but I am not sure they will get around this problem though. > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
On Saturday, 25 August 2018 08:14:40 UTC+10, Pat wrote: > > > I'm assuming if this is only affecting the highchartsDay class - and not > the others - that there's a way to make the day charts play nice with the > other SLEs? > No, it will affect the others, week will be the same, month and year will likely be the same though there could be some subtleties going on as the period increases to match the SummaryBy period. Thinking some more you could check timespan.stop against the last good record in the db and only proceed with the SLE if they match. You could also probably do something to turn off 'highcharts plots' just for the SummaryBy reports, so rather than from [Extras] do it as an option under the [[]] stanzas. I think both are pretty kludgey though. Don't discount a second skin so quickly, it is simple to implement and has the advantage of eliminating a whole pile of db queries. When we put together WeeWX-WD we had 8 reports that used a wide variety of data. Some reports were current point in time and others were full of month, year and alltime aggregates. We split that into 3 skins, it provided a significant improvement in generation time because whole lot of unnecessary db queries no longer occurred. Lazy evaluation of SLE results can improve execution time but I am not sure they will get around this problem though. 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Fair enough. This is where my knowledge of the SLEs is weakest. I'm assuming if this is only affecting the highchartsDay class - and not the others - that there's a way to make the day charts play nice with the other SLEs? On Friday, August 24, 2018 at 6:07:39 PM UTC-4, gjr80 wrote: > > If you are only using 2018 data then no, the year NOAA reports have no > effect. If you include 2017 data then the year NOAA reports will cause the > same issue. Have a look at the very first line of the error trace I posted, > that is due to a yearly NOAA report for 2016. > > There is no conflict/issue with the template, the issue is how SLEs work > when used with reports that iterate over a timespan. > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
If you are only using 2018 data then no, the year NOAA reports have no effect. If you include 2017 data then the year NOAA reports will cause the same issue. Have a look at the very first line of the error trace I posted, that is due to a yearly NOAA report for 2016. There is no conflict/issue with the template, the issue is how SLEs work when used with reports that iterate over a timespan. 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Still trying to do some testing, step by step through the process. It looks like if you remove only the SummaryByMonth NOAA report, the extension completes successfully. So there's some sort of clash between highchartsDay and the NOAA--MM.txt.tmpl template? On Friday, August 24, 2018 at 5:49:38 PM UTC-4, gjr80 wrote: > > Just a point of clarification, well wrongness actually. I said that for > the [[ToDate]] reports the timespan parameter is the current archive > period. It is not, it is in fact the period from the timestamp of first > good record in the archive through until the timestamp of the last record > in the archive. I had incorrectly stated the start time of the period. This > has no effect on my analysis as the timespan start is not used in the > portion of the SLE concerned that generates the error. > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Just a point of clarification, well wrongness actually. I said that for the [[ToDate]] reports the timespan parameter is the current archive period. It is not, it is in fact the period from the timestamp of first good record in the archive through until the timestamp of the last record in the archive. I had incorrectly stated the start time of the period. This has no effect on my analysis as the timespan start is not used in the portion of the SLE concerned that generates the error. 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
I admit I was feeling a bit daft reading through this because I couldn't replicate it. Thanks for providing your test information, it allowed me to to replicate it so I can see the problem first hand. I took my 3 year old database (which was working), copied to a new lab system, truncated it to 2018 only (so 8 months of data) and I'm getting the same error. As you mentioned, if I remove the NOAA reports from skin.conf, it works. If I add them back, it fails. This is an interesting one! I'm a bit lost at this point but now that I can see it fail, I can start to try and wrap my head around it... even though you've already pinpointed it to the [[SummaryByMonth]] and [[SummaryByYear]], there's gotta be a way to make them all co-exist without managing 2 skins? On Friday, August 24, 2018 at 10:19:19 AM UTC-4, gjr80 wrote: > > I'm convinced. Home now so set up a VM running 3.8.2 with no data in the > db. Runs fine. Download user.belchertown_highchartsSearchX.highchartsDay > and add a search_list_extensions option to Standard skin.conf using > user.belchertown_highchartsSearchX.highchartsDay as the only SLE. Runs > without issue (expected). Stop WeeWX, swap in a db with a few months of > simulated data and restart WeeWX and the error occurs: > > Aug 25 00:10:16 stretch21 weewx[26121]: highchartsSearchX: timespan=[2016- > 01-01 00:00:00 AEST (1451570400) -> 2017-01-01 00:00:00 AEST (1483192800)] > _start_ts=1535119200 _end_ts=1535205599 > Aug 25 00:10:16 stretch21 weewx[26121]: reportengine: Caught > unrecoverable exception in generator weewx.cheetahgenerator. > CheetahGenerator > Aug 25 00:10:16 stretch21 weewx[26121]: start time ( > 1535119200) is greater than stop time (1483192800) > Aug 25 00:10:16 stretch21 weewx[26121]: Traceback (most > recent call last): > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/reportengine.py", line 239, in run > Aug 25 00:10:16 stretch21 weewx[26121]: obj.start() > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/reportengine.py", line 273, in start > Aug 25 00:10:16 stretch21 weewx[26121]: self.run() > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/cheetahgenerator.py", line 158, in run > Aug 25 00:10:16 stretch21 weewx[26121]: ngen = self. > generate(gen_dict[section_name], self.gen_ts) > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate > Aug 25 00:10:16 stretch21 weewx[26121]: ngen += self. > generate(section[subsection], gen_ts) > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate > Aug 25 00:10:16 stretch21 weewx[26121]: ngen += self. > generate(section[subsection], gen_ts) > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/cheetahgenerator.py", line 320, in generate > Aug 25 00:10:16 stretch21 weewx[26121]: default_binding) > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weewx/cheetahgenerator.py", line 372, in _getSearchList > Aug 25 00:10:16 stretch21 weewx[26121]: searchList += > obj.get_extension_list(timespan, db_lookup) > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/user/belchertown_highchartsSearchX.py", line 90, in > get_extension_list > Aug 25 00:10:16 stretch21 weewx[26121]: (time_start_vt, > time_stop_vt, outTemp_vt) = db_lookup().getSqlVectors(TimeSpan(_start_ts, > timespan.stop), 'outTemp') > Aug 25 00:10:16 stretch21 weewx[26121]: File > "/home/weewx/bin/weeutil/weeutil.py", line 315, in __new__ > Aug 25 00:10:16 stretch21 weewx[26121]: -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: WS2080 (Rosenborg) weatherstation, reading from current instead of history?
Following up on myself: I got impatient, and using the documentation of rtl_433¹ and weewx-sdr I installed them, and configured weewx thus: [Station] ... station_type = SDR ... [SDR] driver = user.sdr cmd = /usr/local/bin/rtl_433 -q -U -F json -R 32 [[sensor_map]] windGust = wind_gust.76.FOWHx080Packet outBatteryStatus = battery.76.FOWHx080Packet rain_total = rain_total.76.FOWHx080Packet windSpeed = wind_speed.76.FOWHx080Packet windDir = wind_dir.76.FOWHx080Packet outHumidity = humidity.76.FOWHx080Packet outTemp = temperature.76.FOWHx080Packet And it is plotting nicely now: · https://koldfront.dk/weather/ Very cool! Thanks all around, Adam ¹ https://github.com/merbanan/rtl_433 ² https://github.com/matthewwall/weewx-sdr -- "Señor, señor, let’s disconnect these cables Adam Sjøgren Overturn these tables a...@koldfront.dk This place don’t make sense to me no more Can you tell me what we’re waiting for, señor?" -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: WS2080 (Rosenborg) weatherstation, reading from current instead of history?
Andrew writes: > have you tried clearing the memory by power cycling the station - remove > all power - batteries and usb - and start the station again As I wrote in my first email: "I have tried changing batteries, hard resetting it, leaving it unpowered for 14 days, all to no avail." What I meant by "unpowered" was: no usb, batteries removed. It was literally lying on a table for 14 days without any power. (The thing I left out was that I also tried "wee_device --clear_memory".) So: Yes! :-) I guess the station is broken somehow. Or the cable is. We'll see about the latter when the new one I ordered arrives. I guess I could get a new station (I just want outside temperature logged), but I don't feel like researching the options and figuring out what to buy and where... Best regards, Adam -- "Hur långt man än har kommit Adam Sjøgren är det alltid längre kvar" a...@koldfront.dk -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: WS2080 (Rosenborg) weatherstation, reading from current instead of history?
have you tried clearing the memory by power cycling the station - remove all power - batteries and usb - and start the station again On Friday, 24 August 2018 19:39:31 UTC+3, Adam Sjøgren wrote: > > mwall writes: > > > On Thursday, August 23, 2018 at 2:56:23 PM UTC-4, Adam Sjøgren wrote: > > >> Configuring weewx to get information from --current instead the history > >> would be easier [for me, anyway :-)]. Is it possible, and if so, how? > > > first try clearing the station memory - it looks like you might have > > corrupt data in the logger (you could use wee_device to dump the logger > > memory if you really want to go deep) > > I should have mentioned that I had also tried that (using "sudo wee_device > --clear-memory"), besides the other things. > > > also, be sure that your configuration is set to record_generation = > > software > > It wasn't, but flipping it to "software" made no discernable difference > to the end result. > > > if all else fails, you can make weewx think that your driver does not > > support reading of historical records by changing the name of > > genArchiveRecords to xgenArchiveRecords (line 1096 in the file > fousb.py). > > I tried this as well (and restarting weewx afterwards), but still no > updates. > > > finally, beware that the fine offset 10x0/20x0/30x0 stations are very > > sensitive to voltage fluctuations on the usb. sometimes you will see > the > > station randomly reset itself to factory defaults (resulting in an > archive > > interval of 30 minutes). worst case you suffer the usb lockups, which > can > > only be resolved by power cycling the station. > > I haven't seen any of those symptoms, but I have ordered a new cable to > give it a last go before I ditch the station and try the RTL-SDR way. > > Funnily wee_device --current still works a charm, so for my usecase it > would be fine if I could funnel that information into weewx. > > > Thanks for the answer! > > Adam > > -- > "En pessimist i sitt livs form" Adam Sjøgren > > as...@koldfront.dk > -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: WS2080 (Rosenborg) weatherstation, reading from current instead of history?
mwall writes: > On Thursday, August 23, 2018 at 2:56:23 PM UTC-4, Adam Sjøgren wrote: >> Configuring weewx to get information from --current instead the history >> would be easier [for me, anyway :-)]. Is it possible, and if so, how? > first try clearing the station memory - it looks like you might have > corrupt data in the logger (you could use wee_device to dump the logger > memory if you really want to go deep) I should have mentioned that I had also tried that (using "sudo wee_device --clear-memory"), besides the other things. > also, be sure that your configuration is set to record_generation = > software It wasn't, but flipping it to "software" made no discernable difference to the end result. > if all else fails, you can make weewx think that your driver does not > support reading of historical records by changing the name of > genArchiveRecords to xgenArchiveRecords (line 1096 in the file fousb.py). I tried this as well (and restarting weewx afterwards), but still no updates. > finally, beware that the fine offset 10x0/20x0/30x0 stations are very > sensitive to voltage fluctuations on the usb. sometimes you will see the > station randomly reset itself to factory defaults (resulting in an archive > interval of 30 minutes). worst case you suffer the usb lockups, which can > only be resolved by power cycling the station. I haven't seen any of those symptoms, but I have ordered a new cable to give it a last go before I ditch the station and try the RTL-SDR way. Funnily wee_device --current still works a charm, so for my usecase it would be fine if I could funnel that information into weewx. Thanks for the answer! Adam -- "En pessimist i sitt livs form" Adam Sjøgren a...@koldfront.dk -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: weewx_wd
Hallo Danke ich werde das mal Testen.. Am Donnerstag, 22. Februar 2018 22:07:13 UTC+1 schrieb Kalli: > > hallo > > ich benutze WD-Live > da wird aber leider die Mondphase nicht angezeigt. > muss da noch was eingesellt werden. > > > > Hello > > I use WD-Live > but unfortunately the moon phase is not displayed. > there must be something else set up. > > cu. Kalli > > -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: weewx_wd
Hallo Kalli, Die aktuellen Bedingungen werden von WeatherUnderground in festen Intervallen erhalten. Eine Standardinstallation verwendet ein 30-Minuten-Intervall. Sie können dieses Intervall nach oben oder nach unten ändern, auch wenn es keinen Sinn hat, es kürzer als Ihre Senderarchivierungszeit zu haben. Um den Standardwert zu ändern, fügen Sie in der Datei weewx.conf die Option conditions_interval config unter [Weewx-WD] [[Supplementary]] [[[WU]]] wie folgt hinzu: [Weewx-WD] [[Supplementary]] [[[WU]]] conditions_interval = xxx Wobei xxx das gewünschte Intervall in Sekunden ist (Standard ist 1800). Sie müssen WeeWX neu laden oder neu starten, damit die Änderung wirksam wird. Wenn Sie im Logbuch des WeeWX-Startup genau hinsehen, sollten Sie einen Eintrag sehen, der angibt, welche Intervalle verwendet werden (es gibt drei; 'conditions', 'forecast' und 'almanac'). Eine Sache, die wir im Hinterkopf behalten sollten, ist letztendlich, dass WeatherUnderground weiß, wie oft und auf welcher Basis sie ihre aktuellen Daten aktualisieren. The current conditions are obtained from WeatherUnderground at fixed intervals. A default install uses a 30 minute interval. You can change this interval up or down, though there is no point having it any shorter than your station archive period. To change the default add a conditions_interval config option under [Weewx-WD] [[Supplementary]] [[[WU]]] in weewx.conf as follows: [Weewx-WD] [[Supplementary]] [[[WU]]] conditions_interval = xxx where xxx is the interval you want in seconds (default is 1800). You will need to do a config reload or restart WeeWX for the change to take effect. If you look carefully in the log at the WeeWX startup you should see an entry that indicates what intervals are in use (there are three; conditions, forecast and almanac). One thing to keep in mind, ultimately we are at the whim of WeatherUnderground as to how often and on what basis they update their current conditions data. Gruß Gary On Friday, 24 August 2018 18:34:40 UTC+10, Kalli wrote: > > Hallo Gir80 > ich habe festgestellt, das die Anzeige für das Aktuelle Wetter sehr lange > dauert bis diese sich ändert. > Von Sonne nach Regen dauert sehr lange oder ändert sich garnicht, da > sollte noch mal was gemacht werden. > denn wenn es Regnet sollte auch Aktuell: Regen da stehen. > > mfg. Kalli > > Am Donnerstag, 22. Februar 2018 22:07:13 UTC+1 schrieb Kalli: >> >> hallo >> >> ich benutze WD-Live >> da wird aber leider die Mondphase nicht angezeigt. >> muss da noch was eingesellt werden. >> >> >> >> Hello >> >> I use WD-Live >> but unfortunately the moon phase is not displayed. >> there must be something else set up. >> >> cu. Kalli >> >> -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
I'm convinced. Home now so set up a VM running 3.8.2 with no data in the
db. Runs fine. Download user.belchertown_highchartsSearchX.highchartsDay
and add a search_list_extensions option to Standard skin.conf using
user.belchertown_highchartsSearchX.highchartsDay as the only SLE. Runs
without issue (expected). Stop WeeWX, swap in a db with a few months of
simulated data and restart WeeWX and the error occurs:
Aug 25 00:10:16 stretch21 weewx[26121]: highchartsSearchX: timespan=[2016-01
-01 00:00:00 AEST (1451570400) -> 2017-01-01 00:00:00 AEST (1483192800)]
_start_ts=1535119200 _end_ts=1535205599
Aug 25 00:10:16 stretch21 weewx[26121]: reportengine: Caught unrecoverable
exception in generator weewx.cheetahgenerator.CheetahGenerator
Aug 25 00:10:16 stretch21 weewx[26121]: start time (1535119200
) is greater than stop time (1483192800)
Aug 25 00:10:16 stretch21 weewx[26121]: Traceback (most
recent call last):
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/reportengine.py", line 239, in run
Aug 25 00:10:16 stretch21 weewx[26121]: obj.start()
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/reportengine.py", line 273, in start
Aug 25 00:10:16 stretch21 weewx[26121]: self.run()
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/cheetahgenerator.py", line 158, in run
Aug 25 00:10:16 stretch21 weewx[26121]: ngen = self.
generate(gen_dict[section_name], self.gen_ts)
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
Aug 25 00:10:16 stretch21 weewx[26121]: ngen += self.
generate(section[subsection], gen_ts)
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/cheetahgenerator.py", line 232, in generate
Aug 25 00:10:16 stretch21 weewx[26121]: ngen += self.
generate(section[subsection], gen_ts)
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/cheetahgenerator.py", line 320, in generate
Aug 25 00:10:16 stretch21 weewx[26121]: default_binding)
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weewx/cheetahgenerator.py", line 372, in _getSearchList
Aug 25 00:10:16 stretch21 weewx[26121]: searchList += obj.
get_extension_list(timespan, db_lookup)
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/user/belchertown_highchartsSearchX.py", line 90, in
get_extension_list
Aug 25 00:10:16 stretch21 weewx[26121]: (time_start_vt,
time_stop_vt, outTemp_vt) = db_lookup().getSqlVectors(TimeSpan(_start_ts,
timespan.stop), 'outTemp')
Aug 25 00:10:16 stretch21 weewx[26121]: File
"/home/weewx/bin/weeutil/weeutil.py", line 315, in __new__
Aug 25 00:10:16 stretch21 weewx[26121]: raise
ValueError("start
time (%d) is greater than stop time (%d)" % (args[0], args[1]))
Aug 25 00:10:16 stretch21 weewx[26121]: ValueError: start
time (1535119200) is greater than stop time (1483192800)
Aug 25 00:10:16 stretch21 weewx[26121]: Generator terminated
The first line of the log extract is some telemetry I put in highchartsDay
to log timespan, _start_ts and _end_ts. You can see how timespan is 1
January 2016 to 1 January 2017 which is the first year span of data used by
[[SummaryByYear]], the first report in the skin.
Remove the SLE from skin.conf and all reports are generated without error.
Add the SLE back in and the reports continue to be generated without error
(expected since no historical [[SumaryByx]] reports are being
generated, only the 'current' ones.
Delete all the NOAA format reports and next report cycle the error is back.
Like I said, I am convinced.
Gary
On Friday, 24 August 2018 22:57:19 UTC+10, Pat wrote:
>
> Interesting, but my lab system has over 3 years of data without trouble
> with the generator.
>
> On Friday, August 24, 2018 at 8:48:33 AM UTC-4, gjr80 wrote:
>>
>> No, and you won't run into the situation I described unless you have
>> archive data running across multiple months and you force WeeWX to
>> regenerate the [[SummaryByMonth]] reports in your skin (could happen on
>> [[SummaryByYear]] too if you have data spanning multiple years).
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Interesting, but my lab system has over 3 years of data without trouble with the generator. On Friday, August 24, 2018 at 8:48:33 AM UTC-4, gjr80 wrote: > > No, and you won't run into the situation I described unless you have > archive data running across multiple months and you force WeeWX to > regenerate the [[SummaryByMonth]] reports in your skin (could happen on > [[SummaryByYear]] too if you have data spanning multiple years). > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
No, and you won't run into the situation I described unless you have archive data running across multiple months and you force WeeWX to regenerate the [[SummaryByMonth]] reports in your skin (could happen on [[SummaryByYear]] too if you have data spanning multiple years). 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Thanks for the insight Gary. I haven't run into this problem yet - even on brand new VM's with only 5 minutes worth of Simulator data. On Friday, August 24, 2018 at 5:27:05 AM UTC-4, gjr80 wrote: > > Yes I have seen similar errors on numerous occasions, but I have never > seen a cause like this one before. I believe the cause is that the SLEs are > being run against the [[SummaryByMonth]] and [[SummaryByYear]] reports. > > The timespan parameter that is used in the SLE signatures is a TimeSpan > object covering the period of the report. For [[ToDate]] reports this is > typically the period covered by the current archive record, for example the > last 5 minutes. However, the [[SummaryByMonth]] and [[SummaryByYear]] > reports are generated by iterating over all the months and years of data in > the archive, so the period covered varies as the cheetahgenerator iterates > over the months and/or years. For example, the January 2014 NOAA report > will use a timespan of midnight 1 January 2014 until midnight 1 February > 2014. > > The way the SLEs work is that all listed SLEs are evaluated for each > report in a skin, irrespective of whether they are [[SummaryByMonth]], > [[SummaryByYear]] or [[ToDate]] reports. So when the January 2014 NOAA > report is generated the highchartsDay SLE is evaluated using a timespan of > midnight 1 January 2014 until midnight 1 February 2014. Midnight today (24 > August 2018) is used as the start time and midnight 1 February 2014 is used > as the stop time. Consequently the error hits. > > So why does this affect some people some of the time? The answer is in how > the [[SummaryByMonth]] and [[SummaryByYear]] reports are generated. > Normally only the current year and current month reports are generated, > these will not produce the error. However, if a user deletes all of the > generated [[SummaryByMonth]] and [[SummaryByYear]] reports then all of the > reports are regenerated and the error will bite when a historical report is > generated. Same for any one with a clean install with data from more than 1 > month in their archive. > > Solutions, well a couple come to mind: > > 1. Create a second skin to generate the [[SummaryByMonth]] and > [[SummaryByYear]] reports so you can limit the SLE used. > 2. It seems your [[SummaryByMonth]] and [[SummaryByYear]] reports are just > the NOAA format reports, perhaps the Standard skin versions could be used, > but this may be more complex. > 3. Still thinking of number 3. > > 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. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Re: Belchertown skin for weewx now available!
Woke up wondering if this is the classic case of reusing variable names. going to try to replicate it today on a Raspberry Pi. On Fri, Aug 24, 2018, 7:22 AM gjr80 wrote: > Can't comment further without seeing a good couple of archive periods of a > log extract that includes the full error trace. > > Gsry > > -- > 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/GSrKZEiPqsc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > weewx-user+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Can't comment further without seeing a good couple of archive periods of a log extract that includes the full error trace. Gsry -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
With my clean install there was no data in the archive, but the error still occurred. After several hours the situation still persisted. On Friday, 24 August 2018 10:27:05 UTC+1, gjr80 wrote: > > Yes I have seen similar errors on numerous occasions, but I have never > seen a cause like this one before. I believe the cause is that the SLEs are > being run against the [[SummaryByMonth]] and [[SummaryByYear]] reports. > > The timespan parameter that is used in the SLE signatures is a TimeSpan > object covering the period of the report. For [[ToDate]] reports this is > typically the period covered by the current archive record, for example the > last 5 minutes. However, the [[SummaryByMonth]] and [[SummaryByYear]] > reports are generated by iterating over all the months and years of data in > the archive, so the period covered varies as the cheetahgenerator iterates > over the months and/or years. For example, the January 2014 NOAA report > will use a timespan of midnight 1 January 2014 until midnight 1 February > 2014. > > The way the SLEs work is that all listed SLEs are evaluated for each > report in a skin, irrespective of whether they are [[SummaryByMonth]], > [[SummaryByYear]] or [[ToDate]] reports. So when the January 2014 NOAA > report is generated the highchartsDay SLE is evaluated using a timespan of > midnight 1 January 2014 until midnight 1 February 2014. Midnight today (24 > August 2018) is used as the start time and midnight 1 February 2014 is used > as the stop time. Consequently the error hits. > > So why does this affect some people some of the time? The answer is in how > the [[SummaryByMonth]] and [[SummaryByYear]] reports are generated. > Normally only the current year and current month reports are generated, > these will not produce the error. However, if a user deletes all of the > generated [[SummaryByMonth]] and [[SummaryByYear]] reports then all of the > reports are regenerated and the error will bite when a historical report is > generated. Same for any one with a clean install with data from more than 1 > month in their archive. > > Solutions, well a couple come to mind: > > 1. Create a second skin to generate the [[SummaryByMonth]] and > [[SummaryByYear]] reports so you can limit the SLE used. > 2. It seems your [[SummaryByMonth]] and [[SummaryByYear]] reports are just > the NOAA format reports, perhaps the Standard skin versions could be used, > but this may be more complex. > 3. Still thinking of number 3. > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown skin for weewx now available!
Yes I have seen similar errors on numerous occasions, but I have never seen a cause like this one before. I believe the cause is that the SLEs are being run against the [[SummaryByMonth]] and [[SummaryByYear]] reports. The timespan parameter that is used in the SLE signatures is a TimeSpan object covering the period of the report. For [[ToDate]] reports this is typically the period covered by the current archive record, for example the last 5 minutes. However, the [[SummaryByMonth]] and [[SummaryByYear]] reports are generated by iterating over all the months and years of data in the archive, so the period covered varies as the cheetahgenerator iterates over the months and/or years. For example, the January 2014 NOAA report will use a timespan of midnight 1 January 2014 until midnight 1 February 2014. The way the SLEs work is that all listed SLEs are evaluated for each report in a skin, irrespective of whether they are [[SummaryByMonth]], [[SummaryByYear]] or [[ToDate]] reports. So when the January 2014 NOAA report is generated the highchartsDay SLE is evaluated using a timespan of midnight 1 January 2014 until midnight 1 February 2014. Midnight today (24 August 2018) is used as the start time and midnight 1 February 2014 is used as the stop time. Consequently the error hits. So why does this affect some people some of the time? The answer is in how the [[SummaryByMonth]] and [[SummaryByYear]] reports are generated. Normally only the current year and current month reports are generated, these will not produce the error. However, if a user deletes all of the generated [[SummaryByMonth]] and [[SummaryByYear]] reports then all of the reports are regenerated and the error will bite when a historical report is generated. Same for any one with a clean install with data from more than 1 month in their archive. Solutions, well a couple come to mind: 1. Create a second skin to generate the [[SummaryByMonth]] and [[SummaryByYear]] reports so you can limit the SLE used. 2. It seems your [[SummaryByMonth]] and [[SummaryByYear]] reports are just the NOAA format reports, perhaps the Standard skin versions could be used, but this may be more complex. 3. Still thinking of number 3. 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: weewx_wd
Hallo Gir80 ich habe festgestellt, das die Anzeige für das Aktuelle Wetter sehr lange dauert bis diese sich ändert. Von Sonne nach Regen dauert sehr lange oder ändert sich garnicht, da sollte noch mal was gemacht werden. denn wenn es Regnet sollte auch Aktuell: Regen da stehen. mfg. Kalli Am Donnerstag, 22. Februar 2018 22:07:13 UTC+1 schrieb Kalli: > > hallo > > ich benutze WD-Live > da wird aber leider die Mondphase nicht angezeigt. > muss da noch was eingesellt werden. > > > > Hello > > I use WD-Live > but unfortunately the moon phase is not displayed. > there must be something else set up. > > cu. Kalli > > -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Automatic Update to 3.8.2 Multiple Issues [SOLVED]
It is a deb installation, the server is configured for unattended updates. In troubleshooting the issues briefly last week I noticed weewx was a newer version than I recalled, and matched the current version on the website. The backup conf date also matched the last day weewx was posting updates to any of the upstream services, (weathercloud, pws, awekas, cwop, metoffice, wu, and meteotemplate). -- 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: WH3080 always 1013,2 hPa
Hallo ich denke das die Basis Defekt ist. das war mei meiner wh1080 auch drei mal neues Display gekauft. jetzt hab ich die wh-4000 mfg. Kalli Am Donnerstag, 23. August 2018 05:06:04 UTC+2 schrieb BEIJY BUA: > > Good Morning > I have a Problem with my WH3080, it always show at the Display 1013,2 hPa > and the abs Pressure is 000,0. > Has anyone an Idea whats the Problem?? Sensor Demaged?? > > Regards > Chris > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [weewx-user] Re: Belchertown skin for weewx now available!
looks to me like a farenheit to Celsius conversion somewhere is doing the
-32 without also doing the *5/9 ……..
On Friday, 24 August 2018 07:31:32 UTC+3, Colin Larsen wrote:
>
> Just did a brand new install - smooth as butter with no errors that I can
> see.
>
> Pat, can you explain the temp records below for largest and smallest daily
> temp range? Using simulator but I would have thought those temps would be
> in the highest temp above if they were real data?
>
> Highest Temperature 0.4 °C August 24, 2018 at 4:09 PM August 24, 2018 at
> 4:09 PM 0.4 °C
> Lowest Temperature 0.2 °C August 24, 2018 at 4:24 PM August 24, 2018 at
> 4:24 PM 0.2 °C
> Highest Heat Index 0.4 °C August 24, 2018 at 4:09 PM August 24, 2018 at
> 4:09 PM 0.4 °C
> Lowest Wind Chill 0.2 °C August 24, 2018 at 4:24 PM August 24, 2018 at
> 4:24 PM 0.2 °C
> Largest Daily Temperature Range 0.3 °C August 24, 2018
> (Min: 32.4 °C - Max: 32.7 °C ) August 24, 2018
> (Min: 32.4 °C - Max: 32.7 °C ) 0.3 °C
> Smallest Daily Temperature Range 0.3 °C August 24, 2018
> (Min: 32.4 °C - Max: 32.7 °C ) August 24, 2018
> (Min: 32.4 °C - Max: 32.7 °C ) 0.3 °C
>
> On Fri, Aug 24, 2018 at 1:19 PM Pat >
> wrote:
>
>> Strange. Can't pinpoint it. You're both on a Pi, let me get a Pi setup
>> and see if I can figure it out.
>>
>> @gjr80, have you seen this before with your highcharts extension?
>>
>> On Thursday, August 23, 2018 at 8:01:18 PM UTC-4, steep...@gmail.com
>> wrote:
>>>
>>> I am getting a similar problem Juan Antonio
>>>
>>> Aug 24 00:51:48 wxnuc weewx[10832]: default_binding)
>>> Aug 24 00:51:48 wxnuc weewx[10832]: File
>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 372, in _getSearchList
>>> Aug 24 00:51:48 wxnuc weewx[10832]: searchList +=
>>> obj.get_extension_list(timespan, db_lookup)
>>> Aug 24 00:51:48 wxnuc weewx[10832]: File
>>> "/usr/share/weewx/user/belchertown_highchartsSearchX.py", line 88, in
>>> get_extension_list
>>> Aug 24 00:51:48 wxnuc weewx[10832]: (time_start_vt,
>>> time_stop_vt, outTemp_vt) = db_lookup().getSqlVectors(TimeSpan(_start_ts,
>>> timespan.stop), 'outTemp')
>>> Aug 24 00:51:48 wxnuc weewx[10832]: File
>>> "/usr/share/weewx/weeutil/weeutil.py", line 315, in __new__
>>> Aug 24 00:51:48 wxnuc weewx[10832]: raise
>>> ValueError("start time (%d) is greater than stop time (%d)" % (args[0],
>>> args[1]))
>>> Aug 24 00:51:48 wxnuc weewx[10832]: ValueError: start time
>>> (1535065200) is greater than stop time (1483228800)
>>> Aug 24 00:51:48 wxnuc weewx[10832]: Generator terminated
>>> Aug 24 00:51:48 wxnuc weewx[10832]: copygenerator: copied 22 files to
>>> /var/www/html/weewx/belchertown
>>> I have tried it both on an existing WeeWX installation and a clean install.
>>> Rig is a RaspberyPi 3+ with Debian Stretch installed.
>>>
>>>
>>>
>>> On Thursday, August 23, 2018 at 4:47:55 PM UTC+1, Juan Antonio Mosquera
>>> wrote:
Hello,
I have a problem generating...
Aug 23 17:45:25 meteomontaos weewx[12818]: reportengine: Caught
unrecoverable exception in generator
weewx.cheetahgenerator.CheetahGenerator
Aug 23 17:45:25 meteomontaos weewx[12818]: start time
(1534975200) is greater than stop time (1420066800)
Aug 23 17:45:25 meteomontaos weewx[12818]: Traceback (most recent
call last):
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/reportengine.py", line 239, in run
Aug 23 17:45:25 meteomontaos weewx[12818]: obj.start()
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/reportengine.py", line 273, in start
Aug 23 17:45:25 meteomontaos weewx[12818]: self.run()
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/cheetahgenerator.py", line 158, in run
Aug 23 17:45:25 meteomontaos weewx[12818]: ngen =
self.generate(gen_dict[section_name], self.gen_ts)
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
Aug 23 17:45:25 meteomontaos weewx[12818]: ngen +=
self.generate(section[subsection], gen_ts)
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/cheetahgenerator.py", line 232, in generate
Aug 23 17:45:25 meteomontaos weewx[12818]: ngen +=
self.generate(section[subsection], gen_ts)
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/cheetahgenerator.py", line 320, in generate
Aug 23 17:45:25 meteomontaos weewx[12818]: default_binding)
Aug 23 17:45:25 meteomontaos weewx[12818]: File
"/usr/share/weewx/weewx/cheetahgenerator.py", line 372, in _getSearchList
Aug 23
