@gjr80 and @michael Thank you both. On Wednesday, 26 July 2023 at 11:05:13 UTC+2 [email protected] wrote:
> > but any such loss will be minor. > > But often unnecessary and easily avoidable. > > > Bottom line is users should not really need to use the --reweight option > > I use the rebuild option when I have bad values for a single obs_type and > don't want to lose any precision on min/max values and their dateTime, > especially for other obs_types, when fixing them. I just have to ensure > that I take care of the to-be-fixed abs_type min/max values correctly. I > don't know any better way for a scenarios like I just described. I assume > this doesn't apply on the user's scenario since he is missing entire > archive_intervals, but anyway. > > As long as there is no option for wee_database, that manipulates min/max > values and their dateTime only when it is necessary, I will not > --rebuild-daily in such a scenario. > > My bottom line: if you have power outages on a regular basis or even more > than once the one or the other year, fiddling around correcting your > database is not a good approach anyway. You should consider using > a uninterruptible power supply (UPS) for the device weewx is running on > (and, depending on the hardware and network setup/configuration, for the > hardware, DHCP device and switch/access point) and hardware/driver that > supports backfilling to the weewx database. > > > > > > gjr80 schrieb am Mittwoch, 26. Juli 2023 um 10:28:31 UTC+2: > >> Just a few points here. I'm sure it's just a typo that has perpetuated >> itself through the thread, but the default WeeWX database is weewx.sdb >> not weewx.sbd. Also, case matters here. >> >> The recommended approach for correcting spurious data in the database is >> to locate and fix the spurious data in the archive table and then rebuild >> the daily summaries for the period concerned using wee_database. This >> procedure is covered in the Cleaning up old 'bad' data >> <https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data> wiki >> page (note this page details the use of sqlite3 to manipulate the >> archive, these steps can equally be completed using other tools such as DB >> Browser for SQLite etc, also the page currently does not mention the use >> of --from, --to or --date to limit the period of any daily summary >> rebuilds). This may give some loss of max/min values and times but any such >> loss will be minor. >> >> Fixing any spurious data in the daily summary tables by direct editing is >> also possible, but it will likely be time consuming and is prone to error >> and hence not recommended. Consider if there is one anomalous outTemp value >> in a day, first you need to edit and remove the spurious data in the >> archive. Then you would need to locate the day concerned in the outTemp >> daily summary table and edit the max and maxtime fields replacing the >> data with the new max outTemp and the time it occurred for that day >> obtained by looking through that days temperature values in the archive, >> perhaps looking through hundreds of records. If there are other days with >> spurious data you would need to repeat this process for each day. Likewise >> for other obs (remember some obs are derived from others so an anomaly in >> outTemp may cause anomalies in heatindex, windchill, dewpoint etc rain >> anomalies >> may cause anomalies in rainRate). Thus just a few days of anomalous data >> can result in many time consuming changes being required. >> >> Also, the --reweight option was implemented to fix an issue in earlier >> WeeWX versions (post v3.0.0) where archive records in databases with >> multiple different archive intervals were not correctly weighted in the >> daily summary tables. This issue was fixed in v4.3.0 and providing you are >> running v4.3.0 or later the reweighing of the database should only be >> needed as a one-off 'patch' which should have been performed automatically >> on startup of v 4.3.0 or later, all archive records subsequently >> added/modified etc by WeeWX or wee_database are automatically correctly >> weighted. Bottom line is users should not really need to use the >> --reweight option. Note the --reweight option does not perform the same >> function as --rebuild-daily. >> >> Gary >> On Wednesday, 26 July 2023 at 08:31:42 UTC+1 [email protected] wrote: >> >>> 1. Stop service on Raspberry PI. >>> >>> 2. Copy WEEWX.SBD to your PC and open it with DB Browser for SQLite. >>> >>> >>> 3. Using the website https://www.epochconverter.com/ find the >>> approximate dateTime to find the position in the database and change the >>> number in the table "archive". >>> >>> 4. Adjust the maximum value and time in the table "archive_day_xx". >>> >>> >>> 5. Write the changes to the file and copy it back to Raspberry PI. >>> >>> *6. Run sudo wee_database --reweight --date=YYYY-MM-DD (this affects >>> only the particular day you changed values for)* >>> 7. Start the Weewx service. >>> >>> The "reweight" option doesn't touch the min/max values and their >>> timestamp, you took care of that yourself in (4.) >>> >>> [email protected] schrieb am Mittwoch, 26. Juli 2023 um 06:36:17 UTC+2: >>> >>>> >>>> How I hate Google Groups. It looks like I answer only to you Michael. >>>> To be short - your explanation helps me a lot. Thank you. >>>> >>>> I have one more question. Here is how I do it now when I want to change >>>> something manually (for example the rain rate - which is quite often a >>>> problem). >>>> >>>> 1. Stop service on Raspberry PI. >>>> 2. Copy WEEWX.SBD to my PC and open it with DB Browser for SQLite. >>>> 3. Using the website https://www.epochconverter.com/ find the >>>> approximate dateTime to find the position in the database and change the >>>> number in the table "archive". >>>> 4. After your explanation from yesterday change the number in the table >>>> "archive_day_rainRate". >>>> 5. Write the changes to the file and copy it back to Raspberry PI. >>>> 6. Start the Weewx service. >>>> >>>> Is there any better way? >>>> >>>> On Tuesday, 25 July 2023 at 07:45:43 UTC+2 [email protected] wrote: >>>> >>>>> The values are in the "archive_day_*" tables in the database. These >>>>> tables contain a dateTime values, min and max values as well as their >>>>> exact time (depending on the source), sum and weighted sum values and a >>>>> count. When you change a value in the archive table by hand, it won't >>>>> show >>>>> up there, thus not show up in any statistics in the front end, as long as >>>>> you don't fix this in the proper way. >>>>> See https://weewx.com/docs/latest/utilities.htm#wee_database_utility >>>>> for a description of a tool that does it the proper way. Be aware, that >>>>> some actions might lead to loss in precision. For instance, the "exact >>>>> time" I mentioned before is then changed to the dateTime of the archive >>>>> value, e.g. when you maximum gust occurred at 8:33pm using a 5 min >>>>> archive_interval, it might happen, that after running the tool you >>>>> maximum >>>>> gust will be shown at 8:35pm. Or, if your maximum temp was at 4:32pm >>>>> showing 30,1°C with a single loop value of 30,1°C, and all other loop >>>>> values were 30,0°C in that archive_interval, after running the tool, it >>>>> might be, that your maximum will read as 30,0°C at 1:15pm, if that was >>>>> the >>>>> first interval that day, that had 30,0°C. >>>>> >>>>> [email protected] schrieb am Dienstag, 25. Juli 2023 um 06:37:12 UTC+2: >>>>> >>>>>> I had some problems with connections and also physical shocks on >>>>>> sensors. >>>>>> So, I stopped the Weewx service, copy the file >>>>>> /var/lib/weewx/weewx.sdb to my PC. I opened it with >>>>>> SQLiteDatabaseBrowser >>>>>> and change some extreme (unreal) results. For example wind and also >>>>>> rainRate which was caused by the son's ball :-) >>>>>> After that, I copy the file back onto my server and start the Weewx >>>>>> service again. >>>>>> Now some changes are properly shown (for example in graphs), but the >>>>>> max results are old (unreal). I don't understand how this is calculated. >>>>>> I >>>>>> even tried "xstats" and it also shows old (unreal) max results. I >>>>>> checked >>>>>> again in the database and there are no old results there. >>>>>> >>>>>> Any idea how to get rid of "unreal" results which should not apear in >>>>>> the database (and AFAIK they are not there anymore)? >>>>>> >>>>>> Here is the monthly graph where (for example) where we can see wind >>>>>> (VETER) max on the 18th and 19th of July. It was 65 km/h: >>>>>> https://izo.amebis.si/belchertown/graphs/?graph=month >>>>>> >>>>>> Here is a summary where the max wind for July 2023 is 50 km/h: >>>>>> https://izo.amebis.si/belchertown/ >>>>>> >>>>>> It is similar to the rain rate. Max is 13107.0 mm/hr (unreal and I >>>>>> can't find this result in the database (I sorted the rain rate column, >>>>>> tried to check for the particular time ... there is no such data >>>>>> anymore). >>>>>> >>>>>> Regards. >>>>> >>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/5b5296b9-84ea-4475-a52d-c0ecf052c5e5n%40googlegroups.com.
