I was talking about stuff I had at home. Was doing mechanical engineering in '84. But yes I remember those drives and 8" floppies that came after DEC tapes.
This might be the smallest 'drive' you can buy today but it's a sd card, 128mb, https://smile.amazon.com/Cloudisk-Card-SDXC-Flash-Memory/dp/B07RP7JJFN/ The smallest HD is probably about 250gb. Let me try to do a query again. On Tuesday, October 13, 2020 at 12:09:01 PM UTC-4 [email protected] wrote: > I bought a 512 MB disk for a VAX 11 in 1984 for $22,000. It was about the > size of a washing machine. These days, I don't think you can buy a disk > that small. > > On Tue, Oct 13, 2020 at 8:26 AM d k <[email protected]> wrote: > >> All vacuumed up. >> .../weewx_archive.db 770,588,672 >> .../weewx_elec_archive.db 630,120,488 >> >> Still 140,468 kb smaller or 18.2% Again today this isn't an issue. Rather >> small amount of space when you can buy a HD for ~$0.04/gb or less and an SD >> card for ~$0.4/gb or so. >> >> This is a long way from when I started and a mb of HD was $2.79 >> ($2,790/gb) and had an access time of > 20ms. I guess I old habits are hard >> to break. >> >> On Tuesday, October 13, 2020 at 10:44:20 AM UTC-4 d k wrote: >> >>> Maybe this belongs in -development rather than -user? >>> >>> The whole reason for this exercise is that I want to change the schema >>> anyway to add other data from my ted6000 and perhaps a couple of other >>> items like a sensaphone web600 in addition to the weather envoy. So I need >>> columns that aren't in the wview_extended schema. I've figured out how to >>> fix the reports and having the ability to do that makes this a lot easier. >>> >>> And I'm still learning about what tk did when he built this. So it's >>> wonderful that he's an email away. You don't get that often. >>> >>> On Tuesday, October 13, 2020 at 10:27:18 AM UTC-4 d k wrote: >>> >>>> Thought I vacuumed them but doing it again to be sure. They are >>>> separate files and opened in separate processes. I didn't use weewx to >>>> create them. Use the following statements. I'll see what happens. They >>>> don't all have the same data types. I used integers where that works. >>>> >>>> For the unmodified one in file .../weewx_archive.db: >>>> CREATE TABLE "archive" ( >>>> "dateTime" int NOT NULL UNIQUE, >>>> "usUnits" int NOT NULL, >>>> "interval" int NOT NULL, >>>> "barometer" REAL DEFAULT NULL, >>>> "pressure" REAL DEFAULT NULL, >>>> "altimeter" REAL DEFAULT NULL, >>>> "inTemp" REAL DEFAULT NULL, >>>> "outTemp" REAL DEFAULT NULL, >>>> "inHumidity" REAL DEFAULT NULL, >>>> "outHumidity" REAL DEFAULT NULL, >>>> "windSpeed" REAL DEFAULT NULL, >>>> "windDir" REAL DEFAULT NULL, >>>> "windGust" REAL DEFAULT NULL, >>>> "windGustDir" REAL DEFAULT NULL, >>>> "rainRate" REAL DEFAULT NULL, >>>> "rain" REAL DEFAULT NULL, >>>> "dewpoint" REAL DEFAULT NULL, >>>> "windchill" REAL DEFAULT NULL, >>>> "heatindex" REAL DEFAULT NULL, >>>> "ET" REAL REAL, >>>> "radiation" REAL DEFAULT NULL, >>>> "UV" REAL REAL, >>>> "extraTemp1" REAL DEFAULT NULL, >>>> "extraTemp2" REAL DEFAULT NULL, >>>> "extraTemp3" REAL DEFAULT NULL, >>>> "soilTemp1" REAL DEFAULT NULL, >>>> "soilTemp2" REAL DEFAULT NULL, >>>> "soilTemp3" REAL DEFAULT NULL, >>>> "soilTemp4" REAL DEFAULT NULL, >>>> "leafTemp1" REAL DEFAULT NULL, >>>> "leafTemp2" REAL DEFAULT NULL, >>>> "extraHumid1" REAL DEFAULT NULL, >>>> "extraHumid2" REAL DEFAULT NULL, >>>> "soilMoist1" REAL DEFAULT NULL, >>>> "soilMoist2" REAL DEFAULT NULL, >>>> "soilMoist3" REAL DEFAULT NULL, >>>> "soilMoist4" REAL DEFAULT NULL, >>>> "leafWet1" REAL DEFAULT NULL, >>>> "leafWet2" REAL DEFAULT NULL, >>>> "rxCheckPercent" REAL DEFAULT NULL, >>>> "txBatteryStatus" REAL DEFAULT NULL, >>>> "consBatteryVoltage" REAL DEFAULT NULL, >>>> "hail" REAL DEFAULT NULL, >>>> "hailRate" REAL DEFAULT NULL, >>>> "heatingTemp" REAL DEFAULT NULL, >>>> "heatingVoltage" REAL DEFAULT NULL, >>>> "supplyVoltage" REAL DEFAULT NULL, >>>> "referenceVoltage" REAL DEFAULT NULL, >>>> "windBatteryStatus" REAL DEFAULT NULL, >>>> "rainBatteryStatus" REAL DEFAULT NULL, >>>> "outTempBatteryStatus" REAL DEFAULT NULL, >>>> "inTempBatteryStatus" REAL DEFAULT NULL, >>>> PRIMARY KEY("dateTime") >>>> ); >>>> >>>> For the modified one in file .../weewx_elec_archive.db: >>>> CREATE TABLE "archive" ( >>>> "dateTime" INTEGER NOT NULL UNIQUE, >>>> "usUnits" INTEGER DEFAULT NULL, >>>> "interval" INTEGER DEFAULT NULL, >>>> "barometer" REAL DEFAULT NULL, >>>> "pressure" REAL DEFAULT NULL, >>>> "altimeter" REAL DEFAULT NULL, >>>> "inTemp" REAL DEFAULT NULL, >>>> "outTemp" REAL DEFAULT NULL, >>>> "inHumidity" INTEGER DEFAULT NULL, >>>> "outHumidity" INTEGER DEFAULT NULL, >>>> "windSpeed" REAL DEFAULT NULL, >>>> "windDir" REAL DEFAULT NULL, >>>> "windGust" REAL DEFAULT NULL, >>>> "windGustDir" REAL DEFAULT NULL, >>>> "rainRate" REAL DEFAULT NULL, >>>> "rain" REAL DEFAULT NULL, >>>> "dewpoint" REAL DEFAULT NULL, >>>> "windchill" REAL DEFAULT NULL, >>>> "heatindex" REAL DEFAULT NULL, >>>> "ET" REAL DEFAULT NULL, >>>> "radiation" INTEGER DEFAULT NULL, >>>> "UV" REAL DEFAULT NULL, >>>> "soilTemp1" REAL DEFAULT NULL, >>>> "leafTemp1" REAL DEFAULT NULL, >>>> "soilMoist1" INTEGER DEFAULT NULL, >>>> "leafWet1" INTEGER DEFAULT NULL, >>>> "rxCheckPercent" REAL DEFAULT NULL, >>>> "txBatteryStatus" INTEGER DEFAULT NULL, >>>> "consBatteryVoltage" REAL DEFAULT NULL, >>>> PRIMARY KEY("dateTime") >>>> ); >>>> >>>> >>>> On Tuesday, October 13, 2020 at 9:29:18 AM UTC-4 [email protected] >>>> wrote: >>>> >>>>> Oh, one other tip: make sure you VACUUM >>>>> <https://sqlite.org/lang_vacuum.html> both databases before comparing >>>>> sizes. >>>>> >>>>> On Tue, Oct 13, 2020 at 6:27 AM Tom Keffer <[email protected]> wrote: >>>>> >>>>>> How are you running the two benchmarks? In the same process? SQLite >>>>>> caches pages, so the second query should be much faster. >>>>>> >>>>>> Try reversing the order. >>>>>> >>>>>> -tk >>>>>> >>>>>> On Tue, Oct 13, 2020 at 6:18 AM d k <[email protected]> wrote: >>>>>> >>>>>>> I never used SQLite before and my previous comments were based on >>>>>>> mysql. I decided to do an experiment as it was raining yesterday. Read >>>>>>> some >>>>>>> of the SQLite documentation and installed it. Impressed by how >>>>>>> lightweight >>>>>>> it is. >>>>>>> >>>>>>> I have to agree with everyone that the savings from removing all the >>>>>>> unused columns in sqlite is small. In my case 19.3% or from 762,440 kb >>>>>>> to >>>>>>> 615,352 kb = 147,088 kb with 5,480,150 rows. Not insignificant but it >>>>>>> is a >>>>>>> small difference. >>>>>>> >>>>>>> Since I had the two SQLite database files I decided to try a query. >>>>>>> Expected a large time penalty from all the null columns. "SELECT * from >>>>>>> archive WHERE datetime BETWEEN 1490563860 and 1546298910;" on both >>>>>>> files. >>>>>>> I'm doing this on machine other than what I run weewx on, it's much >>>>>>> faster. >>>>>>> >>>>>>> When executed against the unmodified schema: >>>>>>> Execution finished without errors. >>>>>>> Result: 928677 rows returned in 729ms... >>>>>>> >>>>>>> When executed against the modified schema: >>>>>>> Execution finished without errors. >>>>>>> Result: 928677 rows returned in 127ms... >>>>>>> >>>>>>> That is without additional columns I need, which drove this to begin >>>>>>> with. When they are added in as they are null for all of these records >>>>>>> the >>>>>>> execution goes to about 429ms for the modified schema. >>>>>>> >>>>>>> A savings of 602ms or a query that runs in 82.6% less time is, well >>>>>>> huge when it's a simple select statement. >>>>>>> >>>>>>> I haven't tried replacing all the nulls with some value yet. Perhaps >>>>>>> '-1' or some other value those columns would never hold. But the next >>>>>>> rainy >>>>>>> day I just might. >>>>>>> >>>>>>> If you aren't doing a lot of queries on the data this also isn't all >>>>>>> that big a deal. Which was the reason for installing mysql. The nulls >>>>>>> are >>>>>>> the reason you can't normalize the data and have it work acceptable. >>>>>>> >>>>>>> On Sunday, October 11, 2020 at 9:09:23 PM UTC-4 bdf0506 wrote: >>>>>>> >>>>>>>> I've found that deleting columns out of the schema of the archive >>>>>>>> table does more hard than good. I had a 3.x installation for a while, >>>>>>>> and i >>>>>>>> had trimmed many columns that I didn't need, and also renamed some. >>>>>>>> While >>>>>>>> it would work great for general manual querying of the data, many >>>>>>>> skins >>>>>>>> would throw weird errors, mostly when they would expect schemas that >>>>>>>> weren't there. I moved to 4.x recently, and decided to ditch my custom >>>>>>>> schema and go with a fresh install with the extended schema. Exporting >>>>>>>> data >>>>>>>> from the old column names to then importing to the new column names >>>>>>>> proved >>>>>>>> to be trickier than I would have hoped, but eventually got it working >>>>>>>> and >>>>>>>> the had to go and manually update many skins I would use. Overall it >>>>>>>> was a >>>>>>>> PITA and I wish I would have just stuck with the original schema from >>>>>>>> the >>>>>>>> beginning. >>>>>>>> >>>>>>>> tl;dr - stick with the default schemas to save you a headache! >>>>>>>> >>>>>>>> On Saturday, October 10, 2020 at 12:40:53 AM UTC-4 [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> BTW I'm in awe of what you've done with this. It's an amazing >>>>>>>>> effort and I really like what you've done. It works better than many >>>>>>>>> comercial apps I've had to use. >>>>>>>>> >>>>>>>>> On Friday, October 9, 2020 at 6:17:00 PM UTC-4 [email protected] >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry. I should have prefaced my comments that they pertain to >>>>>>>>>> SQLite. I have no experience with MySQL. >>>>>>>>>> >>>>>>>>>> On Fri, Oct 9, 2020 at 8:52 AM d k <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> The size of the indexes on the archive table are <51mb in both >>>>>>>>>>> cases. There is no difference here. I totally agree. >>>>>>>>>>> >>>>>>>>>>> I think the reason you don't see a difference in size is because >>>>>>>>>>> of how null values are stored, I think in 1 byte but haven't found >>>>>>>>>>> a >>>>>>>>>>> reference. So yes even if you remove 20 unused types you only >>>>>>>>>>> remove 20 >>>>>>>>>>> bytes which as you point out is nothing. But the extra columns >>>>>>>>>>> still affect >>>>>>>>>>> read and write performance. Write isn't a big big deal as we don't >>>>>>>>>>> do lots >>>>>>>>>>> of writes anyway. But we might do lots of reads depending on what >>>>>>>>>>> we are >>>>>>>>>>> doing with our station data and we probably are all running this on >>>>>>>>>>> inexpensive slow hardware. In my case a RPi but a new one which >>>>>>>>>>> isn't all >>>>>>>>>>> that slow other than if you're comparing it to something else >>>>>>>>>>> that's new. >>>>>>>>>>> But, for instance it still cut the time to make the daily summiers >>>>>>>>>>> by more >>>>>>>>>>> than half. Again not like we do that often so not a huge deal. >>>>>>>>>>> >>>>>>>>>>> This is where the real change probably came from. I also changed >>>>>>>>>>> the data types of the observations from double (8 bytes) to float >>>>>>>>>>> (4 >>>>>>>>>>> bytes). Mysql made the sqllite data type doubles instead of floats. >>>>>>>>>>> I don't >>>>>>>>>>> have REAL_AS_FLOAT set and that's my fault. >>>>>>>>>>> >>>>>>>>>>> I am going to move to FLOAT(n) and set the precision on the >>>>>>>>>>> columns next which won't change the row length, as the columns are >>>>>>>>>>> all >>>>>>>>>>> still 4 bytes, but to make things easier when I use other >>>>>>>>>>> applications >>>>>>>>>>> against this data set. >>>>>>>>>>> >>>>>>>>>>> In my case the length of the data went from ~1.1 gb to <650mb in >>>>>>>>>>> this case. It also reduced the size of the binlogs, which get >>>>>>>>>>> purged >>>>>>>>>>> anyway. It also reduced the size of the *ib* files. It cut the time >>>>>>>>>>> to and >>>>>>>>>>> size of dumping the table almost by half, I haven't tried restoring >>>>>>>>>>> yet but >>>>>>>>>>> expect the same. Queries run faster. >>>>>>>>>>> >>>>>>>>>>> In my opinion there are other reasons to trim the schema to fit >>>>>>>>>>> your needs other than the size of the data file. But yes it's more >>>>>>>>>>> work and >>>>>>>>>>> that depends on how you use your data if it's worth it or not. >>>>>>>>>>> Obviously I >>>>>>>>>>> think it's worth it and YMMV. >>>>>>>>>>> >>>>>>>>>>> -dk >>>>>>>>>>> On Friday, October 9, 2020 at 9:01:49 AM UTC-4 [email protected] >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Trimming the schema does not make as big a difference in >>>>>>>>>>>> database size as you might think. >>>>>>>>>>>> >>>>>>>>>>>> For example, using my own database of 1.4M rows, trimming the >>>>>>>>>>>> schema from 48 observation types to 27, reduces the size from >>>>>>>>>>>> 268MB to >>>>>>>>>>>> 201MB. >>>>>>>>>>>> >>>>>>>>>>>> The reason is that most of the space is taken up by the >>>>>>>>>>>> indexes, not the column data. >>>>>>>>>>>> >>>>>>>>>>>> -tk >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Oct 8, 2020 at 8:02 PM d k <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yup.. I just found that and was about to report back I was >>>>>>>>>>>>> trying it that was it. Just restarted the test system to see if >>>>>>>>>>>>> it went >>>>>>>>>>>>> away. I think I got rid of all of them now. >>>>>>>>>>>>> >>>>>>>>>>>>> Gary you are the best. Thanks so much. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, October 8, 2020 at 10:54:27 PM UTC-4 gjr80 wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> First up, thank you for not posting images of text, it’s >>>>>>>>>>>>>> makes reading/searching logs a real pain. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The error is due to a skin trying to generate a plot that >>>>>>>>>>>>>> involves extraTemp1 and from the short log extract I would >>>>>>>>>>>>>> guess that this is from the Seasons skin. If you look in the >>>>>>>>>>>>>> Seasons skin config file (skins/Seasons/skin.conf) under >>>>>>>>>>>>>> [ImageGenerator] >>>>>>>>>>>>>> you will find the daytemp, weektemp, monthtemp and yeartemp >>>>>>>>>>>>>> plots use >>>>>>>>>>>>>> extraTemp1 (and extraTemp2 and extraTemp3). Easiest fix is to >>>>>>>>>>>>>> comment out >>>>>>>>>>>>>> those plots, eg: >>>>>>>>>>>>>> >>>>>>>>>>>>>> # [[[daytemp]]] >>>>>>>>>>>>>> # yscale = None, None, 0.5 >>>>>>>>>>>>>> # [[[[extraTemp1]]]] >>>>>>>>>>>>>> # [[[[extraTemp2]]]] >>>>>>>>>>>>>> # [[[[extraTemp3]]]] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Save skin.conf and the error should go away on the next >>>>>>>>>>>>>> report cycle. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gary >>>>>>>>>>>>>> On Friday, 9 October 2020 at 12:29:14 UTC+10 [email protected] >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tried to post this as an image but it doesn't show. So >>>>>>>>>>>>>>> here is the text. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: Caught unrecoverable exception in generator >>>>>>>>>>>>>>> 'weewx.imagegenerator.ImageGenerator' >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** extraTemp1 >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** Traceback (most recent call >>>>>>>>>>>>>>> last): >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** File >>>>>>>>>>>>>>> "/usr/share/weewx/weewx/reportengine.py", line 197, in run >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** obj.start() >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** File >>>>>>>>>>>>>>> "/usr/share/weewx/weewx/reportengine.py", line 280, in start >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** self.run() >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** File >>>>>>>>>>>>>>> "/usr/share/weewx/weewx/imagegenerator.py", line 41, in run >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** >>>>>>>>>>>>>>> self.genImages(self.gen_ts) >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** File >>>>>>>>>>>>>>> "/usr/share/weewx/weewx/imagegenerator.py", line 176, in >>>>>>>>>>>>>>> genImages >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** start_vec_t, stop_vec_t >>>>>>>>>>>>>>> ,data_vec_t = >>>>>>>>>>>>>>> weewx.xtypes.get_series(var_type, >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** File >>>>>>>>>>>>>>> "/usr/share/weewx/weewx/xtypes.py", line 91, in get_series >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** raise >>>>>>>>>>>>>>> weewx.UnknownType(obs_type) >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** weewx.UnknownType: extraTemp1 >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] ERROR >>>>>>>>>>>>>>> weewx.reportengine: **** Generator terminated >>>>>>>>>>>>>>> Oct 8 20:03:19 prometis weewx[271870] DEBUG >>>>>>>>>>>>>>> weewx.reportengine: Report 'SmartphoneReport' not enabled. >>>>>>>>>>>>>>> Skipping. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thursday, October 8, 2020 at 9:39:14 PM UTC-4 Duane >>>>>>>>>>>>>>> Kerzic wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for all the help you provided last time around. >>>>>>>>>>>>>>>> Thanks in advance this time for your help. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I wanted to clean up weewx.archive table and make it a bit >>>>>>>>>>>>>>>> smaller. So I deleted the columns I don't think I'll ever use. >>>>>>>>>>>>>>>> But now I'm >>>>>>>>>>>>>>>> getting this in the system log. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm guessing that extraTemp1 is coded into one of those >>>>>>>>>>>>>>>> files but I haven't looked to find out yet. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've shortened the average row length of the archive table >>>>>>>>>>>>>>>> to 126 from 217 bytes. Huge difference when you have 10 years >>>>>>>>>>>>>>>> of data. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -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 [email protected]. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/weewx-user/02d0a56e-c9fc-4e48-a74a-cdb6291474bbn%40googlegroups.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/02d0a56e-c9fc-4e48-a74a-cdb6291474bbn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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/853cbe79-ee93-49b3-90c3-6a9a02dab1b7n%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/weewx-user/853cbe79-ee93-49b3-90c3-6a9a02dab1b7n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>> 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/77e5e730-9cf0-4dbb-99c1-568d7fd32caen%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/weewx-user/77e5e730-9cf0-4dbb-99c1-568d7fd32caen%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >> 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/a82db714-911b-45df-9f3b-caef8c7f0471n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/a82db714-911b-45df-9f3b-caef8c7f0471n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/8d932786-6a38-4273-94fd-00c248dc3683n%40googlegroups.com.
