[weewx-user] Re: strange behavior with outtemp
Thank you very much El sábado, 3 de agosto de 2019, 16:04:29 (UTC+2), gjr80 escribió: > > I cannot add anything further, since the issue was with a day minimum the > problem almost certainly lay in the daily summaries. The fact the rebuild > fixed it confirms this. Perhaps there was some obscure problem that a > complete rebuild fixed but a day rebuild did not. At least it is working as > intended now. > > Gary > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/daf707b3-8764-41a7-871b-72d07e1d3057%40googlegroups.com.
[weewx-user] Re: strange behavior with outtemp
I did rebuid-daily without --today. Maybe it was necessary to use sudo? Although the owner of the file weewx.sdb is my user. All this happened to me before nightfall on day 8/1, and when I check the table archive_day_outtemp the max datetime was 7/31 22:00. I'm in GMT+2. In the archive table there was also no row with that temperature (0.0) and the graph did not reflect it. It was only in the section min temp of the day where that value continued to appear. Hence my strangeness, because I didn't see that value either in archive or in archive_data_outtemp.I don't know where that data came from, but with drop_daily and rebuild_daily it was fixed. El viernes, 2 de agosto de 2019, 8:22:17 (UTC+2), gjr80 escribió: > > When you say “it didn’t work for you” do you mean using —rebuild-daily > only (ie no —drop-daily first) or using —today? I don’t know why, > rebuilding just the affected day(s) is useful for retaining loop high/low > value and time stamps for unaffected days. Also, sometimes the daily > summary tables need to be dropped first (using —drop-daily) before you > rebuild them. > > The daily summary tables are named ‘archive_day_’ where is an > observation field in the archive table schema. So the outTemp daily summary > table is archive_day_outTemp. Each table consists of a single row per day, > the dateTime field for each row holds the midnight (local time) timestamp. > If I read your post correctly you mention the max outTemp timestamp for 1 > August 2019 is midnight. That could be the case (unlikely but possible for > a day in the past also possible for the current day if you view the data > before sunrise). If you have concerns about the integrity of your data in > the daily summary the best approach is to check the archive table data for > that observation for that day and see whether the daily summary entry is > consistent with the archive data (eg when was the outTemp max on 1 August > according to the archive). During a rebuild the daily summary data is > derived from the archive so there should be no disagreement. > > Gary -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cf983e58-3955-4e5a-a092-b9d5226a5f79%40googlegroups.com.
[weewx-user] Re: strange behavior with outtemp
When you say “it didn’t work for you” do you mean using —rebuild-daily only (ie no —drop-daily first) or using —today? I don’t know why, rebuilding just the affected day(s) is useful for retaining loop high/low value and time stamps for unaffected days. Also, sometimes the daily summary tables need to be dropped first (using —drop-daily) before you rebuild them. The daily summary tables are named ‘archive_day_’ where is an observation field in the archive table schema. So the outTemp daily summary table is archive_day_outTemp. Each table consists of a single row per day, the dateTime field for each row holds the midnight (local time) timestamp. If I read your post correctly you mention the max outTemp timestamp for 1 August 2019 is midnight. That could be the case (unlikely but possible for a day in the past also possible for the current day if you view the data before sunrise). If you have concerns about the integrity of your data in the daily summary the best approach is to check the archive table data for that observation for that day and see whether the daily summary entry is consistent with the archive data (eg when was the outTemp max on 1 August according to the archive). During a rebuild the daily summary data is derived from the archive so there should be no disagreement. Gary -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ac263d20-628a-4389-94b6-6b1e982b8f05%40googlegroups.com.
[weewx-user] Re: strange behavior with outtemp
Thank you but It did not work for me. I did wee_database --drop-daily and rebuild-daily and now it works. But i don't understand, I check archive_daily_outtemp and the max timestamp is from today at midnight(8-1-2109 0:00). Are the summaries not the ones on the daily tables? El jueves, 1 de agosto de 2019, 22:12:23 (UTC+2), gjr80 escribió: > > Hi, > > High/low data for days, weeks, months etc usually comes from the daily > summaries. If you modify the archive to remove/fix erroneous data you need > to rebuild the daily summaries using wee_database with the —rebuild-daily > option (http://weewx.com/docs/utilities.htm#Action_--rebuild-daily). In > your case I would rebuild just the day containing the erroneous data. > > Gary -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/bc345ec6-879e-43ba-8ea5-6d7adc5f3df2%40googlegroups.com.
