Re: [weewx-user] Re: Recommends for new station under 300

[Invisible Man]

Woaw, thanks this is extremely helpful!

The *interceptor* driver (https://github.com/matthewwall/weewx-interceptor) 
looks cool. Except that *I suppose the interceptor needs to be placed where 
it can read all wifi packets* (from the wifi the weather station uses), 
right? 
That's not very convenient in my case because the WiFi is created by the 
Internet box. The Internet box is from my ISP. I don't have any control on 
it, *can't install a weewx driver on it* for instance ;-)
Or can the interceptor be placed on *any machine on the same wifi as the 
weather station* ? 

So, let's investigate the option where I get a *GWyx00* console:

>The communiation from HP25x0 and GWyx00 console goes via WiFi into the 
local LAN.

Ok, so you said that the USB connector on the GWyx00 console was for power 
only. Then, the data from GWyx00 is emitted on WiFi. 
My weewx host (a Rapsberry Pi) is on the LAN. They can ping each other and 
communicate if they wish, no problem.
But will the GWyx00 directly send data to the weewx host: is that 
configurable? *Can I configure the GWxy00 console to communicate with a 
given IP address?* I fear that the GWyx00 console will rather directly send 
its data to an external Internet weather server. Then, same issue, my weewx 
host can't "intercept" the data.

Thanks very much for your help!
On Thursday, August 25, 2022 at 7:10:33 PM UTC+2 lang@googlemail.com 
wrote:

> The HP25x0 consoles do not have an API and cannot be queried via the 
> GW1000 API/Ecowitt Gateway driver.
> You either use a GW1x00/GW2000 instead (receive the same sensors in 
> parallel) with the Ecowtt Gateway (GW1000) driver,
> or you will have to use the weewx Interceptor driver with the HP25x0 
> console custom server functionality
> The interceptor driver as available on GitHub from M. Wall covers only the 
> basic sensors (T/H indoor, outdoor, rain, wind, solar).
> If you have more sensors, you need to use a modified interceptor driver. 
> Some users here have developed an extended version which covers all recent 
> Ecowitt sensors.
>
> The communiation from HP25x0 and GWyx00 console goes via WiFi into the 
> local LAN.
> Weewx will pick up the data via local LAN (LAN or WLAN) depending on the 
> server on which weewx runs and its network interfaces.
>
> There is no USB connection between consoles and weewx
> The USB port on the GW1x00 consoles/gateways is for power supply only. The 
> USB port of the HP25x0 consoles is for factory use initial device firmware 
> only.
>
> On 25.08.2022 19:00, ewhain...@gmail.com wrote:
>
> The IS a USB port on the drawing. I found the manual here: 
> https://www.ecowitt.com/shop/goodsDetail/1# 
>
> Manual & Software tab, Page 7 in the manual, however it also states it is 
> for firmware updates only...
>
> On Thursday, August 25, 2022 at 9:55:10 AM UTC-4 axelle@gmail.com 
> wrote:
>
>> >The GW1100 is included with a number of display-less stations. As I 
>> >understand it, there's a local API and the driver is just talking to 
>> >that API and injecting to weewx.
>>
>> Right. And the GW1100 is plugged by USB to the weewx server, right? or 
>> can weewx read GW1100 over wifi?
>>
>> >it looks like there is the equivalent of the GW1100 inside the console, 
>> >because it says it uploads to similar places
>>
>> I have the feeling the protocol will be the same too. Same reason as you. 
>>
>> The main issue that might occur is whether weewx GW1000 driver is able to 
>> operate via wifi too or not? Looks like the HP2551 console does not have a 
>> USB port (not sure though, couldn't find a photo). And I wasn't able to 
>> find any info on Wifi connection on https://github.com/gjr80/weewx-gw1000 
>> nor about support for HP2551 or HP2552 or HP2553.
>>
>> Anybody from GW1000 driver can answer?
>>
>> Thanks,
>> On Thursday, August 25, 2022 at 12:38:46 PM UTC+2 Greg Troxel wrote:
>>
>>>
>>> Invisible Man  writes: 
>>>
>>> > I'm considering the purchase of a EcoWitt HP2551 : it has a console + 
>>> a 
>>> > 7-in-1 sensor. Just not totally sure how to integrate it with Weewx. 
>>> > People said here to use the Ecowitt GW-1100 driver, right? But EcoWitt 
>>> > HP2551 does not have that GW1100 gateway. Will the driver work 
>>> > nevertheless? 
>>> > Basically, I'm not sure the EcoWitt HP2551 (or 2552, or 2553) has a 
>>> USB 
>>> > cable. So how would I connect it to the RPi on which Weewx runs? 
>>>
>>> I am unclear on details but am heading down the path of figuring out 
>>> which EcoWitt station someone else should get. I lean to EcoWitt 
>>> because it seems to be reasonable quality at very low prices and they 
>>> seem to be open-source and local-access no-cloud-required friendly. So 
>>> many things are cloud-only which I consider a total fail -- the 
>>> interceptor driver is an impressive hack but it's a bad situation that 
>>> it's necesary. 
>>>
>>> The GW1100 is included with a number of display-less stations. As I 
>>> understand it, there's a local API and the driver is 

[weewx-user] Re: Missing rainRate data

[gjr80]

wee_database --calc-missing will only populate missing derived obs provided 
(1) the missing derived obs field contains no data and (2) the 
pre-requisites for the calculation exist. In your case you are failing on 
the first test - your rainRate fields contain the value 0. You can try 
setting the rainRate field to null in each affected record. Assuming you 
are using a SQLite database this is most reliably done using the sqlite3 
utility. To do this:

1. using something like Epoch Converter  to 
determine the epoch timestamp for the first and last archive records in the 
block of records you wish to update, let's refer to these values as 
start_timestamp and end_timestamp

2. install the sqlite3 utility if not already installed:
$ sudo apt install sqlite3

3. stop WeeWX and make a backup of your WeeWX database, unless you have 
changed it this will be /home/weewx/archive/weewx.sdb or 
/var/lib/weewx/weewx.sdb depending on your WeeWX install type 

4. set the rainRate field for the records concerned to null:
$ sqlite3 /home/weewx/archive/weewx.sdb
> UPDATE archive SET rainRate=NULL WHERE dateTime>=start_timestamp AND 
dateTime<=end_timestamp;

replacing start_timestamp and end_timestamp with the actual epoch 
timestamps. You can check the data has been cleared with the following 
query:
> SELECT dateTime,datetime(dateTime, 
'unixepoch','localtime'),rain,rainRate FROM archive 
WHERE dateTime>=start_timestamp AND dateTime<=end_timestamp;

5. once happy the rainRate values have been nulled exit sqlite3 with .q

6. run wee_database --calc-missing to calculate the missing rainRate data, 
use the --date or --from and --to 
 to limit the 
span of records that wee_database will operate on.

7. check the if rainRate has been correctly calculated:
$ sqlite3 /home/weewx/archive/weewx.sdb
> SELECT dateTime,datetime(dateTime, 
'unixepoch','localtime'),rain,rainRate FROM archive 
WHERE dateTime>=start_timestamp AND dateTime<=end_timestamp;
> .q

If you are using MySQL/MariaDB the approach is the same, but you would use 
mysql in lieu of sqlite3.

Gary
On Friday, 26 August 2022 at 05:50:12 UTC+10 peted...@gmail.com wrote:

> I recently (25/08/2022) had to delete a 6 hour section of data from my 
> database as the rain accumulation data contained in the LOOP packets from 
> that period were incorrect. I refilled the database using the correct rain 
> accumulation data from ARCHIVE packets over that 6 hours, and everything 
> (in terms of the daily summaries etc.) now looks good. The only issue I 
> have though is that there is no rainRate data in my database. Looking at a 
> selection of records I can see rain accumulation, but no rainRate:
>
> dateTime|rain  |rainRate
> 2022-08-25 06:15:00|1.018610|0.0
> 2022-08-25 06:20:00|0.978673|0.0
> 2022-08-25 06:25:00|1.367165|0.0
> 2022-08-25 06:30:00|1.710911|0.0
> 2022-08-25 06:35:00|1.588113|0.0
> 2022-08-25 06:40:00|1.858461|0.0
> 2022-08-25 06:45:00|1.654587|0.0
> 2022-08-25 06:50:00|1.475450|0.0
> 2022-08-25 06:55:00|1.498110|0.0
>
> I have tried using wee_database --calc-missing as I assumed rainRate was a 
> derived value, but this doesn't seem to have made any difference. Can 
> anyone advise how to fill the missing rainRate fields?
>

-- 
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/150e83c7-73a7-4756-a2df-6bdd753dce38n%40googlegroups.com.

Re: [weewx-user] Re: Reading station error

[p q]

The found station at bus= device= is a clue. It's not finding the device
correctly. There should be something other than blanks after the equal
signs.

If you're verified you're in Mode 3 on the display unit, and your USB is
working correctly on the Pi, I don't know what else to suggest. Are there
any other USB errors in the log?

On Thu, Aug 25, 2022 at 10:01 AM ewhain...@gmail.com 
wrote:

> anyone?
>
> On Wednesday, August 24, 2022 at 9:46:31 AM UTC-4 ewhain...@gmail.com
> wrote:
>
>> Acurite 5-in-1. I was reading data, but having an FTP error (turned out
>> to be provider error) so I did an update/upgrade and now WeeWx will see the
>> station but not read data. I have tried resetting the station, switching
>> through USB modes, different USB ports on the RPi...
>>
>> Here is error log:
>>
>> Aug 24 09:40:48 weatherpi weewx[17995] DEBUG weewx.drivers.acurite: Found
>> station at bus= device=
>> Aug 24 09:40:49 weatherpi weewx[17995] ERROR weewx.drivers.acurite:
>> Failed attempt 1 of 10 to get LOOP data: [Errno 110] Operation timed out
>> Aug 24 09:41:19 weatherpi weewx[17995] DEBUG weewx.drivers.acurite: Found
>> station at bus= device=
>> Aug 24 09:41:19 weatherpi weewx[17995] ERROR weewx.drivers.acurite:
>> Failed attempt 2 of 10 to get LOOP data: [Errno 32] Pipe error
>>
>> Any ideas why the RPi will see the device but not get the data??
>>
>> TIA
>>
>> EWH
>>
> --
> 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/e1f067a8-b221-41d9-8992-463dfa51f9den%40googlegroups.com
> 
> .
>


-- 
Peter Quinn
(415)794-2264

-- 
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/CAA1SM20385G8gzcjjnDOimxg6GA1CFV8AT--R%3DCUjgTkfiv29A%40mail.gmail.com.

[weewx-user] Missing rainRate data

[Peter Cooper-Davis]

I recently (25/08/2022) had to delete a 6 hour section of data from my 
database as the rain accumulation data contained in the LOOP packets from 
that period were incorrect. I refilled the database using the correct rain 
accumulation data from ARCHIVE packets over that 6 hours, and everything 
(in terms of the daily summaries etc.) now looks good. The only issue I 
have though is that there is no rainRate data in my database. Looking at a 
selection of records I can see rain accumulation, but no rainRate:

dateTime|rain  |rainRate
2022-08-25 06:15:00|1.018610|0.0
2022-08-25 06:20:00|0.978673|0.0
2022-08-25 06:25:00|1.367165|0.0
2022-08-25 06:30:00|1.710911|0.0
2022-08-25 06:35:00|1.588113|0.0
2022-08-25 06:40:00|1.858461|0.0
2022-08-25 06:45:00|1.654587|0.0
2022-08-25 06:50:00|1.475450|0.0
2022-08-25 06:55:00|1.498110|0.0

I have tried using wee_database --calc-missing as I assumed rainRate was a 
derived value, but this doesn't seem to have made any difference. Can 
anyone advise how to fill the missing rainRate fields?

-- 
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/9f468d7b-f667-4658-bbfa-8242a85a11den%40googlegroups.com.

Re: [weewx-user] Re: Recommends for new station under 300

[Rainer Lang]

The HP25x0 consoles do not have an API and cannot be queried via the 
GW1000 API/Ecowitt Gateway driver.
You either use a GW1x00/GW2000 instead (receive the same sensors in 
parallel) with the Ecowtt Gateway (GW1000) driver,
or you will have to use the weewx Interceptor driver with the HP25x0 
console custom server functionality
The interceptor driver as available on GitHub from M. Wall covers only 
the basic sensors (T/H indoor, outdoor, rain, wind, solar).
If you have more sensors, you need to use a modified interceptor driver. 
Some users here have developed an extended version which covers all 
recent Ecowitt sensors.


The communiation from HP25x0 and GWyx00 console goes via WiFi into the 
local LAN.
Weewx will pick up the data via local LAN (LAN or WLAN) depending on the 
server on which weewx runs and its network interfaces.


There is no USB connection between consoles and weewx
The USB port on the GW1x00 consoles/gateways is for power supply only. 
The USB port of the HP25x0 consoles is for factory use initial device 
firmware only.


On 25.08.2022 19:00, ewhain...@gmail.com wrote:
The IS a USB port on the drawing. I found the manual here: 
https://www.ecowitt.com/shop/goodsDetail/1#


Manual & Software tab, Page 7 in the manual, however it also states it 
is for firmware updates only...


On Thursday, August 25, 2022 at 9:55:10 AM UTC-4 axelle@gmail.com 
wrote:


>The GW1100 is included with a number of display-less stations. As I
>understand it, there's a local API and the driver is just talking to
>that API and injecting to weewx.

Right. And the GW1100 is plugged by USB to the weewx server,
right? or can weewx read GW1100 over wifi?

>it looks like there is the equivalent of the GW1100 inside the
console,
>because it says it uploads to similar places

I have the feeling the protocol will be the same too. Same reason
as you.

The main issue that might occur is whether weewx GW1000 driver is
able to operate via wifi too or not? Looks like the HP2551 console
does not have a USB port (not sure though, couldn't find a photo).
And I wasn't able to find any info on Wifi connection on
https://github.com/gjr80/weewx-gw1000 nor about support for HP2551
or HP2552 or HP2553.

Anybody from GW1000 driver can answer?

Thanks,
On Thursday, August 25, 2022 at 12:38:46 PM UTC+2 Greg Troxel wrote:


Invisible Man  writes:

> I'm considering the purchase of a EcoWitt HP2551 : it has a
console + a
> 7-in-1 sensor. Just not totally sure how to integrate it
with Weewx.
> People said here to use the Ecowitt GW-1100 driver, right?
But EcoWitt
> HP2551 does not have that GW1100 gateway. Will the driver work
> nevertheless?
> Basically, I'm not sure the EcoWitt HP2551 (or 2552, or
2553) has a USB
> cable. So how would I connect it to the RPi on which Weewx
runs?

I am unclear on details but am heading down the path of
figuring out
which EcoWitt station someone else should get. I lean to EcoWitt
because it seems to be reasonable quality at very low prices
and they
seem to be open-source and local-access no-cloud-required
friendly. So
many things are cloud-only which I consider a total fail -- the
interceptor driver is an impressive hack but it's a bad
situation that
it's necesary.

The GW1100 is included with a number of display-less stations.
As I
understand it, there's a local API and the driver is just
talking to
that API and injecting to weewx. Thus it should work if the
internet is
down (or if the GW1100 is firewalled to keep the data from
being sent to
their cloud), but I'm not 100% sure as sometimes devices have
code that
phones home and stops if that doesn't work.

Reading

https://shop.ecowitt.com/products/hp2551

it looks like there is the equivalent of the GW1100 inside the
console,
because it says it uploads to similar places, and there is a
list of
optional sensors that seems to match. It would be sane to
offer the
same API and for them to reuse their code and circuit design,
just
sharing the case/etc. -- and doing so would be consistent with my
impression of EcoWitt's approach.

However, skimming the driver github site I don't see direct
confirmation
that the HP2551 is wire-protocol compatible. With any luck
someone will
post that they've used the driver.

--
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 
http

[weewx-user] Re: Reading station error

[ewhain...@gmail.com]

anyone? 

On Wednesday, August 24, 2022 at 9:46:31 AM UTC-4 ewhain...@gmail.com wrote:

> Acurite 5-in-1. I was reading data, but having an FTP error (turned out to 
> be provider error) so I did an update/upgrade and now WeeWx will see the 
> station but not read data. I have tried resetting the station, switching 
> through USB modes, different USB ports on the RPi...
>
> Here is error log:
>
> Aug 24 09:40:48 weatherpi weewx[17995] DEBUG weewx.drivers.acurite: Found 
> station at bus= device=
> Aug 24 09:40:49 weatherpi weewx[17995] ERROR weewx.drivers.acurite: Failed 
> attempt 1 of 10 to get LOOP data: [Errno 110] Operation timed out
> Aug 24 09:41:19 weatherpi weewx[17995] DEBUG weewx.drivers.acurite: Found 
> station at bus= device=
> Aug 24 09:41:19 weatherpi weewx[17995] ERROR weewx.drivers.acurite: Failed 
> attempt 2 of 10 to get LOOP data: [Errno 32] Pipe error
>
> Any ideas why the RPi will see the device but not get the data??
>
> TIA
>
> EWH
>

-- 
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/e1f067a8-b221-41d9-8992-463dfa51f9den%40googlegroups.com.

Re: [weewx-user] Re: Recommends for new station under 300

[ewhain...@gmail.com]

The IS a USB port on the drawing. I found the manual 
here: https://www.ecowitt.com/shop/goodsDetail/1#

Manual & Software tab, Page 7 in the manual, however it also states it is 
for firmware updates only...

On Thursday, August 25, 2022 at 9:55:10 AM UTC-4 axelle@gmail.com wrote:

> >The GW1100 is included with a number of display-less stations. As I 
> >understand it, there's a local API and the driver is just talking to 
> >that API and injecting to weewx.
>
> Right. And the GW1100 is plugged by USB to the weewx server, right? or can 
> weewx read GW1100 over wifi?
>
> >it looks like there is the equivalent of the GW1100 inside the console, 
> >because it says it uploads to similar places
>
> I have the feeling the protocol will be the same too. Same reason as you. 
>
> The main issue that might occur is whether weewx GW1000 driver is able to 
> operate via wifi too or not? Looks like the HP2551 console does not have a 
> USB port (not sure though, couldn't find a photo). And I wasn't able to 
> find any info on Wifi connection on https://github.com/gjr80/weewx-gw1000 
> nor about support for HP2551 or HP2552 or HP2553.
>
> Anybody from GW1000 driver can answer?
>
> Thanks,
> On Thursday, August 25, 2022 at 12:38:46 PM UTC+2 Greg Troxel wrote:
>
>>
>> Invisible Man  writes:
>>
>> > I'm considering the purchase of a EcoWitt HP2551 : it has a console + a 
>> > 7-in-1 sensor. Just not totally sure how to integrate it with Weewx.
>> > People said here to use the Ecowitt GW-1100 driver, right? But EcoWitt 
>> > HP2551 does not have that GW1100 gateway. Will the driver work 
>> > nevertheless? 
>> > Basically, I'm not sure the EcoWitt HP2551 (or 2552, or 2553) has a USB 
>> > cable. So how would I connect it to the RPi on which Weewx runs?
>>
>> I am unclear on details but am heading down the path of figuring out
>> which EcoWitt station someone else should get. I lean to EcoWitt
>> because it seems to be reasonable quality at very low prices and they
>> seem to be open-source and local-access no-cloud-required friendly. So
>> many things are cloud-only which I consider a total fail -- the
>> interceptor driver is an impressive hack but it's a bad situation that
>> it's necesary.
>>
>> The GW1100 is included with a number of display-less stations. As I
>> understand it, there's a local API and the driver is just talking to
>> that API and injecting to weewx. Thus it should work if the internet is
>> down (or if the GW1100 is firewalled to keep the data from being sent to
>> their cloud), but I'm not 100% sure as sometimes devices have code that
>> phones home and stops if that doesn't work.
>>
>> Reading
>>
>> https://shop.ecowitt.com/products/hp2551
>>
>> it looks like there is the equivalent of the GW1100 inside the console,
>> because it says it uploads to similar places, and there is a list of
>> optional sensors that seems to match. It would be sane to offer the
>> same API and for them to reuse their code and circuit design, just
>> sharing the case/etc. -- and doing so would be consistent with my
>> impression of EcoWitt's approach.
>>
>> However, skimming the driver github site I don't see direct confirmation
>> that the HP2551 is wire-protocol compatible. With any luck someone will
>> post that they've used the driver.
>>
>>

-- 
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/f99be245-5334-4b28-bb66-7229fdee4569n%40googlegroups.com.

Re: [weewx-user] Re: Recommends for new station under 300

[Invisible Man]

>The GW1100 is included with a number of display-less stations. As I 
>understand it, there's a local API and the driver is just talking to 
>that API and injecting to weewx.

Right. And the GW1100 is plugged by USB to the weewx server, right? or can 
weewx read GW1100 over wifi?

>it looks like there is the equivalent of the GW1100 inside the console, 
>because it says it uploads to similar places

I have the feeling the protocol will be the same too. Same reason as you. 

The main issue that might occur is whether weewx GW1000 driver is able to 
operate via wifi too or not? Looks like the HP2551 console does not have a 
USB port (not sure though, couldn't find a photo). And I wasn't able to 
find any info on Wifi connection on https://github.com/gjr80/weewx-gw1000 
nor about support for HP2551 or HP2552 or HP2553.

Anybody from GW1000 driver can answer?

Thanks,
On Thursday, August 25, 2022 at 12:38:46 PM UTC+2 Greg Troxel wrote:

>
> Invisible Man  writes:
>
> > I'm considering the purchase of a EcoWitt HP2551 : it has a console + a 
> > 7-in-1 sensor. Just not totally sure how to integrate it with Weewx.
> > People said here to use the Ecowitt GW-1100 driver, right? But EcoWitt 
> > HP2551 does not have that GW1100 gateway. Will the driver work 
> > nevertheless? 
> > Basically, I'm not sure the EcoWitt HP2551 (or 2552, or 2553) has a USB 
> > cable. So how would I connect it to the RPi on which Weewx runs?
>
> I am unclear on details but am heading down the path of figuring out
> which EcoWitt station someone else should get. I lean to EcoWitt
> because it seems to be reasonable quality at very low prices and they
> seem to be open-source and local-access no-cloud-required friendly. So
> many things are cloud-only which I consider a total fail -- the
> interceptor driver is an impressive hack but it's a bad situation that
> it's necesary.
>
> The GW1100 is included with a number of display-less stations. As I
> understand it, there's a local API and the driver is just talking to
> that API and injecting to weewx. Thus it should work if the internet is
> down (or if the GW1100 is firewalled to keep the data from being sent to
> their cloud), but I'm not 100% sure as sometimes devices have code that
> phones home and stops if that doesn't work.
>
> Reading
>
> https://shop.ecowitt.com/products/hp2551
>
> it looks like there is the equivalent of the GW1100 inside the console,
> because it says it uploads to similar places, and there is a list of
> optional sensors that seems to match. It would be sane to offer the
> same API and for them to reuse their code and circuit design, just
> sharing the case/etc. -- and doing so would be consistent with my
> impression of EcoWitt's approach.
>
> However, skimming the driver github site I don't see direct confirmation
> that the HP2551 is wire-protocol compatible. With any luck someone will
> post that they've used the driver.
>
>

-- 
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/4080d5f8-0bba-44b0-ab3f-8d4a529c118cn%40googlegroups.com.

[weewx-user] Re: WeatherCat import Vs Daylight Savings Time

[kurand]

Thanks for confirming what I understood from weeimport.py and 
weathercatimport.py.

I am using "derived' for the import because I originally configured 
WeatherCat with Adaptive interval set true so I have data logged at 
varying  rates from 1 minute all the way up to 30+ minute intervals. 

I think in this case, weathercatimport.py needs to use timezone aware 
date-time objects during its construction of dateTime else data will become 
misplaced and DST changes will fail as noted. Once this is accomplished, 
then something needs to get added to deal with the apparent bug in 
WeatherCat where transitioning from standard time to daylight saving time 
in spring causes it to skip an extra hour forward sometimes. It looks to me 
like this can all be isolated in weathercatimport.py's getRawData function. 

I'm curious to know if anyone else has run into this problem, or if it is 
something specific to my WeatherCat data. Or perhaps WeatherCat import has 
been used in anger. 

On Thursday, August 25, 2022 at 11:59:34 AM UTC+1 gjr80 wrote:

> If you are using 'derive' to derive the archive interval from the imported 
> data then the imported records must be in ascending timestamp/date-time 
> order. This is because the derived archive interval is calculated by taking 
> the difference between the timestamp of the current record and the 
> timestamp of the previous record. If the calculated interval is negative it 
> indicates the records being imported are not in timestamp order and the 
> calculated archive interval cannot be trusted. The import will abort.
>
> This should not present a problem at the start of a daylight saving period 
> where clocks jump forward (though the archive interval would be incorrectly 
> calculated for the first record after daylight saving begins). It would 
> certainly cause a problem at the end of a period of daylight saving where 
> clocks jump back in time.
>
> So what to do? WeeWX date-time objects are timezone naive 
>  
> so managing daylight saving is near impossible. I would suggest removing 
> the data to be imported with the duplicate date-times (which set of 
> duplicates I leave up to you) and re-trying the import. You might also want 
> to consider using a fixed interval (if your data does indeed have a fixed 
> interval) rather than deriving it from the data. FWIW, the vantage driver 
> has a similar issue in that each year when daylight saving ends the driver 
> receives archive records with duplicate timestamps, in this case the 
> situation is handled slightly more gracefully in that WeeWX ignores the 
> duplicate timestamped records with a 'PRIMARY KEY must be unique' error. 
> wee_import is somewhat less forgiving.
>
> Gary
> On Thursday, 25 August 2022 at 00:45:13 UTC+10 kurand wrote:
>
>> Has anyone successfully imported data from WeatherCat for months where 
>> Daylight Savings Time starts or ends? 
>>
>> When I have tried this, I get the following type of error (example for 
>> Oct-2017):
>>
>> Cannot derive 'interval' for record timestamp: 2017-10-29 01:00:00 BST 
>> (1509235200).
>>
>>  Raw data is not in ascending date time order.
>>
>> Looking at the 7 years of data I have logged by WeatherCat, it appears 
>> that WeatherCat does not really handle DST transitions very well. Data is 
>> generally logging in local time.
>>
>> For spring DST changes (in March for my UK based timezone), it seems 
>> usually to jump forward by two hours at 0100 going to 0300 rather than just 
>> one hour as you'd expect. It then tack on an hours worth of data for day 01 
>> at the end of the month. This gives rise to the above error when the end of 
>> the month's data is processed. However, for some reason, in my data for 
>> 2014, it does only jump forward one hour as expected and there was no extra 
>> data logged at the end of the month. 
>>
>> For autumn DST changes (in October in UK timezone), it seems to jump back 
>> an hour at 0200, so it repeats log entries for hour 0100 again. This gives 
>> rise to the above error.
>>
>> It's all a bit of a mess really; I'm not sure if its just my WeatherCat 
>> data, or the way I configured it with Adaptive interval set true or 
>> something else. 
>>
>> Does anyone have a fix for this, or do I need to work something out.
>>
>

-- 
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/369e8880-dcbb-4028-9d4f-dbf775a8fa5bn%40googlegroups.com.

Re: [weewx-user] Re: Recommends for new station under 300

[Bill Arthur]

I don't know about the HP2551, but I know a bit about the GW1100 phoning 
home. 
I first found it on a solar powered station with no internet.
The GW1100 doesn't stop, but it resets it's WiFi every 10 minutes if it 
can't touch home.
The community was great with helping to find a solution. I spoofed it to 
using a local server, 
and I also had to provide a local time server in order to get rain 
measurements.


On Thursday, August 25, 2022 at 5:38:46 AM UTC-5 Greg Troxel wrote:

> As I 
> understand it, there's a local API and the driver is just talking to 
> that API and injecting to weewx. Thus it should work if the internet is 
> down (or if the GW1100 is firewalled to keep the data from being sent to 
> their cloud), but I'm not 100% sure as sometimes devices have code that 
> phones home and stops if that doesn't work. 
>
>
>

-- 
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/4c47057d-d0fe-4a03-b01e-7e45c9978ba4n%40googlegroups.com.

Re: [weewx-user] Re: sum vs wsum for archive_day_rain

[gjr80]

> So even for monthly average temperature I guess I can use sum instead of 
wsum.

Well no, because you do not know whether the archive interval for all of 
the records is the same. For obs, such as rain, where you are interested in 
the absolute sum for each day (or month or year) you use the sum field. 
Think of it this way, it doesn't matter what the archive interval is for a 
cumulative measurement such as rain, the total rain for the day (or month 
or year) is the sum of the rain recorded in each archive interval in that 
day (or month or year). When considering temperature (or any other 
non-cumulative obs) you are using the average temperature for the day (or 
month or year) and this calculation does vary if the archive interval for 
each record varies so you need to use wsum.

Gary
On Thursday, 25 August 2022 at 20:33:32 UTC+10 pravee...@gmail.com wrote:

> Thanks. That makes sense. So even for monthly average temperature I guess 
> I can use sum instead of wsum. I am using wsum for temperature (monthly 
> average) now and it seems to work fine. It was when I attempted it for rain 
> that it went all wrong and then i modified the query based on obs_type. I 
> am actually updating xaggs.py to support monthly and yearly averages.
>
> On Thu, 25 Aug 2022 at 15:41, gjr80  wrote:
>
>> As a general rule if you are working with averages you should be using 
>> wsum and sumtime, but it really depends on what you are calculating. To 
>> understand you need to know what the daily summary wsum field contains 
>> and how it is different to the sum field. I have no idea what the time 
>> field is, do you perhaps mean the sumtime field?
>>
>> WeeWX v3.0.0 introduced support for different archive interval values 
>> within a single database, hand in glove with this change was the 
>> introduction of weighting of archive record values used in the daily 
>> summaries. This was done to ensure that archive records with long archive 
>> intervals did not skew certain aggregates. For example, if a database 
>> contained archive records with a five minute interval during the night and 
>> archive records with a 30 minute archive interval during the day, when the 
>> average temperature was calculated for the entire day the resulting 
>> calculated value would be low due to there being up to six times more 
>> nighttime temperature values than there are daytime values. So a 
>> temperature of 15C at 11pm that 'applied' for five minutes would carry the 
>> same weight in the day average temperature as a 30C temperature at 11am 
>> that 'applied' for 30 minutes. 
>>
>> The solution is to weight the archive record values by the archive 
>> interval. This is what is stored in the daily summary wsum field (the sum 
>> field is retained as an unweighted sum). Archive interval weighting was not 
>> properly implemented in v3.0.0 resulting in all archive records being 
>> weighted equally irrespective of archive interval. This was fixed variously 
>> in v3.7.0, v4.2.0, v4.3.0 and v4.4.0 (as an aside, users with a homogeneous 
>> archive interval value in their database still use archive record 
>> weighting, but each archive record is weighted equally).
>>
>> For obs where you are interested in the average value for the day, such 
>> as temperature, wind speed etc, the correct daily average value is the 
>> wsum value divided by the sumtime value. If you look in the WeeWX xtypes 
>> module 
>>  
>> you will see the queries used for daily summary based averages use the 
>> wsum and sumtime fields. However, for rain  there is little sense in 
>> 'averaging' the day rain total as is done with say temperature. Typically 
>> for rain we are interested in the daily total or the sum field. You will 
>> see in the xtypes module the queries for the daily summary based sums use 
>> the sum field (you can still calculate the 'day average rain' using 
>> $day.rain.avg, which will use the rain daily summary wsum value, but it 
>> is a fairly meaningless aggregate).
>>
>> In your case, if what you refer to as 'monthly averages for rainfall' is 
>> the average monthly rainfall (ie average July rainfall, average August 
>> rainfall etc), I expect you would be wanting the sum of the rainfall for 
>> the month (eg the sum of the rainfall for each July or the sum of the sum 
>> fields for each day in each July) and average that over the number of those 
>> months in your data (ie the number of 'Julys'). I wouldn't see you using 
>> wsum or sumtime.
>>
>> Gary
>> On Thursday, 25 August 2022 at 15:27:34 UTC+10 pravee...@gmail.com wrote:
>>
>>> Hi,
>>>
>>> When trying to build monthly averages for rainfall, I see that using 
>>> SUM(sum) from archive_day_rain gives sensible data while doing 
>>> SUM(wsum)/SUM(wtime) gives very weird data. What should be used for 
>>> archive_day_rain?
>>>
>>> Regards,
>>> Praveen
>>>
>> -- 
>> You received this message because you are subscribed to 

[weewx-user] Re: WeatherCat import Vs Daylight Savings Time

[gjr80]

If you are using 'derive' to derive the archive interval from the imported 
data then the imported records must be in ascending timestamp/date-time 
order. This is because the derived archive interval is calculated by taking 
the difference between the timestamp of the current record and the 
timestamp of the previous record. If the calculated interval is negative it 
indicates the records being imported are not in timestamp order and the 
calculated archive interval cannot be trusted. The import will abort.

This should not present a problem at the start of a daylight saving period 
where clocks jump forward (though the archive interval would be incorrectly 
calculated for the first record after daylight saving begins). It would 
certainly cause a problem at the end of a period of daylight saving where 
clocks jump back in time.

So what to do? WeeWX date-time objects are timezone naive 
 
so managing daylight saving is near impossible. I would suggest removing 
the data to be imported with the duplicate date-times (which set of 
duplicates I leave up to you) and re-trying the import. You might also want 
to consider using a fixed interval (if your data does indeed have a fixed 
interval) rather than deriving it from the data. FWIW, the vantage driver 
has a similar issue in that each year when daylight saving ends the driver 
receives archive records with duplicate timestamps, in this case the 
situation is handled slightly more gracefully in that WeeWX ignores the 
duplicate timestamped records with a 'PRIMARY KEY must be unique' error. 
wee_import is somewhat less forgiving.

Gary
On Thursday, 25 August 2022 at 00:45:13 UTC+10 kurand wrote:

> Has anyone successfully imported data from WeatherCat for months where 
> Daylight Savings Time starts or ends? 
>
> When I have tried this, I get the following type of error (example for 
> Oct-2017):
>
> Cannot derive 'interval' for record timestamp: 2017-10-29 01:00:00 BST 
> (1509235200).
>
>  Raw data is not in ascending date time order.
>
> Looking at the 7 years of data I have logged by WeatherCat, it appears 
> that WeatherCat does not really handle DST transitions very well. Data is 
> generally logging in local time.
>
> For spring DST changes (in March for my UK based timezone), it seems 
> usually to jump forward by two hours at 0100 going to 0300 rather than just 
> one hour as you'd expect. It then tack on an hours worth of data for day 01 
> at the end of the month. This gives rise to the above error when the end of 
> the month's data is processed. However, for some reason, in my data for 
> 2014, it does only jump forward one hour as expected and there was no extra 
> data logged at the end of the month. 
>
> For autumn DST changes (in October in UK timezone), it seems to jump back 
> an hour at 0200, so it repeats log entries for hour 0100 again. This gives 
> rise to the above error.
>
> It's all a bit of a mess really; I'm not sure if its just my WeatherCat 
> data, or the way I configured it with Adaptive interval set true or 
> something else. 
>
> Does anyone have a fix for this, or do I need to work something out.
>

-- 
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/6d619c5f-77ca-4025-800d-5aeb0e3c8856n%40googlegroups.com.

Re: [weewx-user] Re: Recommends for new station under 300

[Greg Troxel]

Invisible Man  writes:

> I'm considering the purchase of a EcoWitt HP2551 : it has a console + a 
> 7-in-1 sensor. Just not totally sure how to integrate it with Weewx.
> People said here to use the Ecowitt GW-1100 driver, right? But EcoWitt 
> HP2551 does not have that GW1100 gateway. Will the driver work 
> nevertheless? 
> Basically, I'm not sure the EcoWitt HP2551 (or 2552, or 2553) has a USB 
> cable. So how would I connect it to the RPi on which Weewx runs?

I am unclear on details but am heading down the path of figuring out
which EcoWitt station someone else should get.  I lean to EcoWitt
because it seems to be reasonable quality at very low prices and they
seem to be open-source and local-access no-cloud-required friendly.  So
many things are cloud-only which I consider a total fail -- the
interceptor driver is an impressive hack but it's a bad situation that
it's necesary.

The GW1100 is included with a number of display-less stations.  As I
understand it, there's a local API and the driver is just talking to
that API and injecting to weewx.  Thus it should work if the internet is
down (or if the GW1100 is firewalled to keep the data from being sent to
their cloud), but I'm not 100% sure as sometimes devices have code that
phones home and stops if that doesn't work.

Reading

  https://shop.ecowitt.com/products/hp2551

it looks like there is the equivalent of the GW1100 inside the console,
because it says it uploads to similar places, and there is a list of
optional sensors that seems to match.  It would be sane to offer the
same API and for them to reuse their code and circuit design, just
sharing the case/etc. -- and doing so would be consistent with my
impression of EcoWitt's approach.

However, skimming the driver github site I don't see direct confirmation
that the HP2551 is wire-protocol compatible.  With any luck someone will
post that they've used the driver.

-- 
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/rmimtbs621a.fsf%40s1.lexort.com.


signature.asc
Description: PGP signature

Re: [weewx-user] Re: sum vs wsum for archive_day_rain

[Praveen Chandrasekaran]

Thanks. That makes sense. So even for monthly average temperature I guess I
can use sum instead of wsum. I am using wsum for temperature (monthly
average) now and it seems to work fine. It was when I attempted it for rain
that it went all wrong and then i modified the query based on obs_type. I
am actually updating xaggs.py to support monthly and yearly averages.

On Thu, 25 Aug 2022 at 15:41, gjr80  wrote:

> As a general rule if you are working with averages you should be using
> wsum and sumtime, but it really depends on what you are calculating. To
> understand you need to know what the daily summary wsum field contains
> and how it is different to the sum field. I have no idea what the time
> field is, do you perhaps mean the sumtime field?
>
> WeeWX v3.0.0 introduced support for different archive interval values
> within a single database, hand in glove with this change was the
> introduction of weighting of archive record values used in the daily
> summaries. This was done to ensure that archive records with long archive
> intervals did not skew certain aggregates. For example, if a database
> contained archive records with a five minute interval during the night and
> archive records with a 30 minute archive interval during the day, when the
> average temperature was calculated for the entire day the resulting
> calculated value would be low due to there being up to six times more
> nighttime temperature values than there are daytime values. So a
> temperature of 15C at 11pm that 'applied' for five minutes would carry the
> same weight in the day average temperature as a 30C temperature at 11am
> that 'applied' for 30 minutes.
>
> The solution is to weight the archive record values by the archive
> interval. This is what is stored in the daily summary wsum field (the sum
> field is retained as an unweighted sum). Archive interval weighting was not
> properly implemented in v3.0.0 resulting in all archive records being
> weighted equally irrespective of archive interval. This was fixed variously
> in v3.7.0, v4.2.0, v4.3.0 and v4.4.0 (as an aside, users with a homogeneous
> archive interval value in their database still use archive record
> weighting, but each archive record is weighted equally).
>
> For obs where you are interested in the average value for the day, such as
> temperature, wind speed etc, the correct daily average value is the wsum
> value divided by the sumtime value. If you look in the WeeWX xtypes module
>  you
> will see the queries used for daily summary based averages use the wsum
> and sumtime fields. However, for rain  there is little sense in
> 'averaging' the day rain total as is done with say temperature. Typically
> for rain we are interested in the daily total or the sum field. You will
> see in the xtypes module the queries for the daily summary based sums use
> the sum field (you can still calculate the 'day average rain' using
> $day.rain.avg, which will use the rain daily summary wsum value, but it
> is a fairly meaningless aggregate).
>
> In your case, if what you refer to as 'monthly averages for rainfall' is
> the average monthly rainfall (ie average July rainfall, average August
> rainfall etc), I expect you would be wanting the sum of the rainfall for
> the month (eg the sum of the rainfall for each July or the sum of the sum
> fields for each day in each July) and average that over the number of those
> months in your data (ie the number of 'Julys'). I wouldn't see you using
> wsum or sumtime.
>
> Gary
> On Thursday, 25 August 2022 at 15:27:34 UTC+10 pravee...@gmail.com wrote:
>
>> Hi,
>>
>> When trying to build monthly averages for rainfall, I see that using
>> SUM(sum) from archive_day_rain gives sensible data while doing
>> SUM(wsum)/SUM(wtime) gives very weird data. What should be used for
>> archive_day_rain?
>>
>> Regards,
>> Praveen
>>
> --
> 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/zbg1X8dMRvQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/567c6084-bf8f-491e-a800-bedb8e3bbd21n%40googlegroups.com
> 
> .
>

-- 
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/CA%2BW%3DTmVAFpKJMui6i_Ch9q%2Bg%3DozGfsYyFkuxybMCdJW%2BqVGpZQ%40mail.gmail.com.

[weewx-user] Re: sum vs wsum for archive_day_rain

[gjr80]

As a general rule if you are working with averages you should be using wsum 
and sumtime, but it really depends on what you are calculating. To 
understand you need to know what the daily summary wsum field contains and 
how it is different to the sum field. I have no idea what the time field 
is, do you perhaps mean the sumtime field?

WeeWX v3.0.0 introduced support for different archive interval values 
within a single database, hand in glove with this change was the 
introduction of weighting of archive record values used in the daily 
summaries. This was done to ensure that archive records with long archive 
intervals did not skew certain aggregates. For example, if a database 
contained archive records with a five minute interval during the night and 
archive records with a 30 minute archive interval during the day, when the 
average temperature was calculated for the entire day the resulting 
calculated value would be low due to there being up to six times more 
nighttime temperature values than there are daytime values. So a 
temperature of 15C at 11pm that 'applied' for five minutes would carry the 
same weight in the day average temperature as a 30C temperature at 11am 
that 'applied' for 30 minutes. 

The solution is to weight the archive record values by the archive 
interval. This is what is stored in the daily summary wsum field (the sum 
field is retained as an unweighted sum). Archive interval weighting was not 
properly implemented in v3.0.0 resulting in all archive records being 
weighted equally irrespective of archive interval. This was fixed variously 
in v3.7.0, v4.2.0, v4.3.0 and v4.4.0 (as an aside, users with a homogeneous 
archive interval value in their database still use archive record 
weighting, but each archive record is weighted equally).

For obs where you are interested in the average value for the day, such as 
temperature, wind speed etc, the correct daily average value is the wsum 
value divided by the sumtime value. If you look in the WeeWX xtypes module 
 you 
will see the queries used for daily summary based averages use the wsum and 
sumtime fields. However, for rain  there is little sense in 'averaging' the 
day rain total as is done with say temperature. Typically for rain we are 
interested in the daily total or the sum field. You will see in the xtypes 
module the queries for the daily summary based sums use the sum field (you 
can still calculate the 'day average rain' using $day.rain.avg, which will 
use the rain daily summary wsum value, but it is a fairly meaningless 
aggregate).

In your case, if what you refer to as 'monthly averages for rainfall' is 
the average monthly rainfall (ie average July rainfall, average August 
rainfall etc), I expect you would be wanting the sum of the rainfall for 
the month (eg the sum of the rainfall for each July or the sum of the sum 
fields for each day in each July) and average that over the number of those 
months in your data (ie the number of 'Julys'). I wouldn't see you using 
wsum or sumtime.

Gary
On Thursday, 25 August 2022 at 15:27:34 UTC+10 pravee...@gmail.com wrote:

> Hi,
>
> When trying to build monthly averages for rainfall, I see that using 
> SUM(sum) from archive_day_rain gives sensible data while doing 
> SUM(wsum)/SUM(wtime) gives very weird data. What should be used for 
> archive_day_rain?
>
> Regards,
> Praveen
>

-- 
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/567c6084-bf8f-491e-a800-bedb8e3bbd21n%40googlegroups.com.

[weewx-user] Re: Recommends for new station under 300

[Invisible Man]

I'm considering the purchase of a EcoWitt HP2551 : it has a console + a 
7-in-1 sensor. Just not totally sure how to integrate it with Weewx.
People said here to use the Ecowitt GW-1100 driver, right? But EcoWitt 
HP2551 does not have that GW1100 gateway. Will the driver work 
nevertheless? 
Basically, I'm not sure the EcoWitt HP2551 (or 2552, or 2553) has a USB 
cable. So how would I connect it to the RPi on which Weewx runs?
Thanks.

On Wednesday, August 10, 2022 at 7:20:37 PM UTC+2 lang@googlemail.com 
wrote:

> You want to learn more about the FineOffset / Ecowitt weather station and 
> sensor "ecosystem", look up 
> https://www.wxforum.net/index.php?topic=40730.0
>
> For prices of stations/combinations check www.ecowitt.com - depending on 
> your location there may also be resellers of the same hardware with a 
> different branding
> (this is also explained in the above link)
> Am 10.08.2022 um 19:17 schrieb Bill Arthur:
>
> If you aren't concerned about a console you can get set up for half of 
> your $300 budget. In fact you can buy two systems. (Keep one as a spare)
> I use the Ambient Weather WS-2902 array ($132) and the Ecowitt GW-1100  
> ($30)
> The array is accurate, has spare parts readily available and is well 
> supported. The weewx driver for the GW-1100 is excellent.
>
> On Wednesday, August 10, 2022 at 11:36:57 AM UTC-5 Bob Atchley wrote:
>
>> If you can get one of these Weather stations in your location: 
>>
>> Bresser PC 5 in 1 - 7002571
>> Logia 5-in-1 PC - LOWSB510PB
>>
>> They are well below your budget, buffer 50 days worth of data, are 
>> reasonably accurate and have usb connection for PC (and hence weewx 
>> support).
>> Make sure the console supports the PC connection (lots of very similar 
>> models are wifi only)
>>
>> On Wednesday, 10 August 2022 at 16:56:34 UTC+1 vince wrote:
>>
>>> And https://www.scientificsales.com - both places have good prices and 
>>> provide nice customer service... 
>>>
>>> On Wednesday, August 10, 2022 at 8:25:30 AM UTC-7 storm...@gmail.com 
>>> wrote:
>>>
 Check out Scaled Instruments: 


 https://www.scaledinstruments.com/product-category/davis-instruments/complete-weather-stations/vantage-vue-series/

 -- 
> 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/db7b5860-e166-440e-8a54-db55c8ac70fdn%40googlegroups.com
>  
> 
> .
>
>

-- 
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/7d089c4a-83fc-4a4f-b3c3-9512f3060454n%40googlegroups.com.