from:"Rainer Lang"

[weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]

2024-06-04 Thread 'Rainer Lang' via weewx-user

olling the console API in an interval < 79s, you get the 
lightning data updates more frequently than 79s.

Your information does not fit the observed reality. Whats true is that 
you need to store lightning data in a different format, to calculate a 
meaningful value for the archive record. Something like the count per 
interval and a kind of weighted average for the distance. It exists 
for the Tempest, which transmits lightning data using UDP as it 
detects a lightning. Apart from the other data which is transmitted in 
a constant interval.

Rainer Lang schrieb am Montag, 3. Juni 2024 um 17:25:34 UTC+2:

"If there is a possibility to extract a singled detected lightning
event and
> it's data with standard devices, is another story. If so, I'd
see the point
> of doing so. At least the minimal distance and weighted average
distance
> are interesting values to me. I doubt it is possible doing this
with the
> "Ecowitt Gateway Driver", I have no idea if it is possible with the
> interceptor driver and a WH2551, it should be possible using SDR."

what part of transmitting every 79 seconds has not been understood ?
And the 79 seconds start with the first detected discharge.

Why would SDR receive more and more often ? Magic SDR ?
SDR is nothing else but a radio receiver as is a console.
Just by changing the console the sensor won't post faster.

And it's not an Acurite chipset (maybe some Acurite device uses
the same chip);
it's an AS3935 - before starting wild speculations I would read
the specifications and see if the chip can be animated to provide
data more frequently.
Then you can try your luck modifying the sensor firmware if that's
possible and not limited by the chip itself ...

And have a look what exactly the chip provides/can provide ...
check if it provides such things like minimal distance, weighted
distance etc.
Nice wishlist, but as far as I have understood the specifications,
it doesn't do that.
Admittedly, I'm not an expert here - somebody else may be able to
extract more information

Google can be your friend - look up the AS3935 specifications/data
sheet etc.

But as for the WH57 as manufactured, it will transmit every 79
seconds 

And it has nothing to do with the Ecowitt Gateway driver or any
other driver - you can have it poll every two seconds.
But it can get only what the console has available to send. And
the console only has what it receives from what was transmitted.

Maybe it would be helpful to understand how weewx works ...

Classically the data received from a driver or extension is
collected in a loop where data gets accumulated.
That doesn't seem to be what you want. You seem to want every
single data-item to be recorded separately.
Then you will also have to write the code which does this and save
the data in a way you can reuse it - i.e. write your own extension.
You'd probably need your own separate lightning database for that too.
In the typical way weewx works, collects and archives data that
won't work as far as I can see.

By the way - if there are no more discharges within 79 seconds,
your request above will be fulfilled 

all the sensor related information could have been found and read
in the Ecowitt WiKi
https://meshka.eu/Ecowitt/dokuwiki

On 02.06.2024 19:25, 'michael.k...@gmx.at' via weewx-user wrote:

Probably the only way getting reasonable data is with SDR.

michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um
07:32:51 UTC+2:

My best guess is that the Sensor reports every 79s "Hello,
I'm there" and every detected lightning on top of that,
    immediately. If you don't live at Catatumbo River mouth, this
shouldn't drain the battery too much. Let's see if Rainer
Lang knows more Details.

Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48
UTC+2:

"michael.k...@gmx.at"  writes:

> I am just now in the middle of this Storm with
stroboscopic-like lightning
> flashing.
>
> I recognized my HP2551 is obviously showing lightning
strikes in realtime.
> Every one or the other second.
>
> Then I checked back in the manual and now disagree with
gjr80, when he
> states:
>
> gjr80 schrieb am Mittwoch, 21. Juni 2023 um 22:32:42
UTC+2:
>
> In essence the WH57 reports three things; the number of
lightning strike
> detected today, the time of the last detected lightning
strike and the
> distance of the last lightning

[weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [3]

2024-06-03 Thread 'Rainer Lang' via weewx-user

"If there is a possibility to extract a singled detected lightning event 
and
> it's data with standard devices, is another story. If so, I'd see the 
point

> of doing so. At least the minimal distance and weighted average distance
> are interesting values to me. I doubt it is possible doing this with the
> "Ecowitt Gateway Driver", I have no idea if it is possible with the
> interceptor driver and a WH2551, it should be possible using SDR."

what part of transmitting every 79 seconds has not been understood ?
And the 79 seconds start with the first detected discharge.

Why would SDR receive more and more often ? Magic SDR ?
SDR is nothing else but a radio receiver as is a console.
Just by changing the console the sensor won't post faster.

And it's not an Acurite chipset (maybe some Acurite device uses the same 
chip);
it's an AS3935 - before starting wild speculations I would read the 
specifications and see if the chip can be animated to provide data more 
frequently.
Then you can try your luck modifying the sensor firmware if that's 
possible and not limited by the chip itself ...

And have a look what exactly the chip provides/can provide ...
check if it provides such things like minimal distance, weighted 
distance etc.
Nice wishlist, but as far as I have understood the specifications, it 
doesn't do that.
Admittedly, I'm not an expert here - somebody else may be able to 
extract more information

Google can be your friend - look up the AS3935 specifications/data sheet 
etc.

But as for the WH57 as manufactured, it will transmit every 79 seconds 

And it has nothing to do with the Ecowitt Gateway driver or any other 
driver - you can have it poll every two seconds.
But it can get only what the console has available to send. And the 
console only has what it receives from what was transmitted.

Maybe it would be helpful to understand how weewx works ...

Classically the data received from a driver or extension is collected in 
a loop where data gets accumulated.
That doesn't seem to be what you want. You seem to want every single 
data-item to be recorded separately.
Then you will also have to write the code which does this and save the 
data in a way you can reuse it - i.e. write your own extension.

You'd probably need your own separate lightning database for that too.
In the typical way weewx works, collects and archives data that won't 
work as far as I can see.

By the way - if there are no more discharges within 79 seconds, your 
request above will be fulfilled 

all the sensor related information could have been found and read in the 
Ecowitt WiKi

https://meshka.eu/Ecowitt/dokuwiki

On 02.06.2024 19:25, 'michael.k...@gmx.at' via weewx-user wrote:

Probably the only way getting reasonable data is with SDR.

michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um 07:32:51 UTC+2:

My best guess is that the Sensor reports every 79s "Hello, I'm
there" and every detected lightning on top of that, immediately.
If you don't live at Catatumbo River mouth, this shouldn't drain
    the battery too much. Let's see if Rainer Lang knows more Details.

Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48 UTC+2:

"michael.k...@gmx.at"  writes:

> I am just now in the middle of this Storm with
stroboscopic-like lightning
> flashing.
>
> I recognized my HP2551 is obviously showing lightning
strikes in realtime.
> Every one or the other second.
>
> Then I checked back in the manual and now disagree with
gjr80, when he
> states:
>
> gjr80 schrieb am Mittwoch, 21. Juni 2023 um 22:32:42 UTC+2:
>
> In essence the WH57 reports three things; the number of
lightning strike
> detected today, the time of the last detected lightning
strike and the
> distance of the last lightning strike. This is clearly
stated in the WH57
> manual.
> Gary

This sounds very much like the chip that is in the Acurite 6045M

> If there is a possibility to extract a singled detected
lightning event and
> it's data with standard devices, is another story. If so,
I'd see the point
> of doing so. At least the minimal distance and weighted
average distance
> are interesting values to me. I doubt it is possible doing
this with the
> "Ecowitt Gateway Driver", I have no idea if it is possible
with the
> interceptor driver and a WH2551, it should be possible using
SDR.

Certainly it would be great to log the bits and study them.
The 6045M
only transmits periodically, with a longer period without
lightning and
then faster in 'active mode'. I suspect the chip

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user


in addition, look up

https://weewx.com/docs/5.0/utilities/weectl-station/#create-a-new-station-data-directory

there you find the example how to create a Vantage station (of course 
the values for altitude, longitude, latitude have to be replaced by your 
values)


|weectl station create --no-prompt --driver=weewx.drivers.vantage \ 
--altitude="400,foot" --latitude=45.1 --longitude=-105.9 \ 
--location="My Special Station"|


the result should be a properly configured weewx.conf

On 20.03.2024 01:20, Rainer Lang wrote:


try reading (and applying) https://weewx.com/docs/5.0/hardware/vantage/

On 20.03.2024 01:07, Sidney wrote:

Type: Davis Vantage Pro2/Vue
Station model: WeatherDuino 4Pro DB
Connection: TCP/IP
IP: http://192.168.0.39

Thank you Rainer.
On Wednesday, March 20, 2024 at 12:42:51 AM UTC+1 Rainer Lang wrote:

I'm not sure if you have understood the weewx concepts ...

What would be the use of changing skins - except you don't like
the Seasons skin 
But  before you do this, you better get weewx running with the
default Seasons skin.
Once running, you can add or switch skins.

You probably want to use data from your station - then you have
to change your station, not the skin

You need to install the driver for your station ...

So you have to install the respective weewx driver for your
station which would then replace the Simulator station.

What's your station ? Brand, model ?

On 20.03.2024 00:35, Sidney wrote:

I was able to instal nginx. yay! Thanks for advising me.
Screenshot 2024-03-20 at 0.26.53.png
I'm now trying:
change the skin and get out of simulation to real data.
Unfortunately, I have no luck with it.
I'm using the following:

# Stop the daemonsudosystemctlstopweewx # Reconfigure to use
your hardwareweectlstationreconfigure # Delete the old
databaserm/var/lib/weewx/weewx.sdb # Start the
daemonsudosystemctlstartweewx
But seems it does not reflect my selected meteo station and
keeps using Simulation.

The same with skin which I try to change in*etc/weewx/weewx.conf
*but it does not reflect anything.

I'm sorry for these questions, your support is very helpful.
On Tuesday, March 19, 2024 at 11:58:18 PM UTC+1 Sidney wrote:

I do follow now. Thank you for the explanation. I'm now
trying to install a web server to get the page load on the
local network. Let's see whats next then. Thanks again.

On Tuesday, March 19, 2024 at 11:54:09 PM UTC+1 Rainer Lang
wrote:

@Sidney - I think you are confusing a few things and are
comparing apples with pears.
You may not be aware of the functionality of and the
need to have a webserver (program).
CumulusMX has an inbuilt webserver, but not one which is
available to users other than the CMX users.
So when you can reach CMX via a defined port and the URL
of your weewx server e.g. IP:8998 this doesn't mean that
a generally available webserver is installed.

So, as Vince already mentioned, a webserver like nginx
or apache2 needs to be installed for you to see the
weewx skin via a browser via the URL.
You can of course open /var/www/html/weewx/index.html in
a web browser by loading it into the browser, but to
reach it via the URL ip-address/weewx a webserver is
needed which has access to the html-root (default
/var/www/html) and subdirectories and replies to your
http request.

On 19.03.2024 23:43, Sidney wrote:

Thank you, Vince.
Seems I'm a bit lost in it and will be exploring it to
find the trouble.

On Tuesday, March 19, 2024 at 10:57:24 PM UTC+1 vince
wrote:

You didn't provide enough detail to really
understand your setup.   Does Cumulus MX have some
software it runs that responds on port 8998 ?

Did you even install a normal webserver such as
nginx or apache ? If not, see the wiki (link)

<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
 for
how to do install one and hook it together with weewx.

On Tuesday, March 19, 2024 at 1:23:58 PM UTC-7
Sidney wrote:

Thank you for a quick response. web server is
for sure installed as I do see Cumulus web server:
Screenshot 2024-03-19 at 21.20.46.png
When I try to go to http://192.168.0.40/weewx
I'm getting  This site can’t be reached. Sorry
for probably a silly question. Appreciate your
support. THank you.

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user


try reading (and applying) https://weewx.com/docs/5.0/hardware/vantage/

On 20.03.2024 01:07, Sidney wrote:

Type: Davis Vantage Pro2/Vue
Station model: WeatherDuino 4Pro DB
Connection: TCP/IP
IP: http://192.168.0.39

Thank you Rainer.
On Wednesday, March 20, 2024 at 12:42:51 AM UTC+1 Rainer Lang wrote:

I'm not sure if you have understood the weewx concepts ...

What would be the use of changing skins - except you don't like
the Seasons skin 
But  before you do this, you better get weewx running with the
default Seasons skin.
Once running, you can add or switch skins.

You probably want to use data from your station - then you have to
change your station, not the skin

You need to install the driver for your station ...

So you have to install the respective weewx driver for your
station which would then replace the Simulator station.

What's your station ? Brand, model ?

On 20.03.2024 00:35, Sidney wrote:

I was able to instal nginx. yay! Thanks for advising me.
Screenshot 2024-03-20 at 0.26.53.png
I'm now trying:
change the skin and get out of simulation to real data.
Unfortunately, I have no luck with it.
I'm using the following:

# Stop the daemonsudosystemctlstopweewx # Reconfigure to use your
hardwareweectlstationreconfigure # Delete the old
databaserm/var/lib/weewx/weewx.sdb # Start the
daemonsudosystemctlstartweewx
But seems it does not reflect my selected meteo station and keeps
using Simulation.

The same with skin which I try to change in*etc/weewx/weewx.conf
*but it does not reflect anything.

I'm sorry for these questions, your support is very helpful.
On Tuesday, March 19, 2024 at 11:58:18 PM UTC+1 Sidney wrote:

I do follow now. Thank you for the explanation. I'm now
trying to install a web server to get the page load on the
local network. Let's see whats next then. Thanks again.

On Tuesday, March 19, 2024 at 11:54:09 PM UTC+1 Rainer Lang
wrote:

@Sidney - I think you are confusing a few things and are
comparing apples with pears.
You may not be aware of the functionality of and the need
to have a webserver (program).
CumulusMX has an inbuilt webserver, but not one which is
available to users other than the CMX users.
So when you can reach CMX via a defined port and the URL
of your weewx server e.g. IP:8998 this doesn't mean that
a generally available webserver is installed.

So, as Vince already mentioned, a webserver like nginx or
apache2 needs to be installed for you to see the weewx
skin via a browser via the URL.
You can of course open /var/www/html/weewx/index.html in
a web browser by loading it into the browser, but to
reach it via the URL ip-address/weewx a webserver is
needed which has access to the html-root (default
/var/www/html) and subdirectories and replies to your
http request.

On 19.03.2024 23:43, Sidney wrote:

Thank you, Vince.
Seems I'm a bit lost in it and will be exploring it to
find the trouble.

On Tuesday, March 19, 2024 at 10:57:24 PM UTC+1 vince wrote:

You didn't provide enough detail to really
understand your setup.   Does Cumulus MX have some
software it runs that responds on port 8998 ?

Did you even install a normal webserver such as
nginx or apache ?   If not, see the wiki (link)

<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
 for
how to do install one and hook it together with weewx.

On Tuesday, March 19, 2024 at 1:23:58 PM UTC-7
Sidney wrote:

Thank you for a quick response. web server is
for sure installed as I do see Cumulus web server:
Screenshot 2024-03-19 at 21.20.46.png
When I try to go to http://192.168.0.40/weewx
I'm getting  This site can’t be reached. Sorry
for probably a silly question. Appreciate your
support. THank you.

On Tuesday, March 19, 2024 at 9:12:41 PM UTC+1
    Rainer Lang wrote:

correct, but weewx (its Seasons skin)
doesn't have a realtime dashboard (except
you install the mqtt based Belchertown skin).
The update interval is defined in weewx.conf
and could go down to one minute instead of
five minutes (in theory - in practice to be
found out if the reports can co

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user


I'm not sure if you have understood the weewx concepts ...

What would be the use of changing skins - except you don't like the 
Seasons skin 
But  before you do this, you better get weewx running with the default 
Seasons skin.

Once running, you can add or switch skins.

You probably want to use data from your station - then you have to 
change your station, not the skin


You need to install the driver for your station ...

So you have to install the respective weewx driver for your station 
which would then replace the Simulator station.


What's your station ? Brand, model ?

On 20.03.2024 00:35, Sidney wrote:

I was able to instal nginx. yay! Thanks for advising me.
Screenshot 2024-03-20 at 0.26.53.png
I'm now trying:
change the skin and get out of simulation to real data. Unfortunately, 
I have no luck with it.

I'm using the following:

# Stop the daemonsudosystemctlstopweewx # Reconfigure to use your 
hardwareweectlstationreconfigure # Delete the old 
databaserm/var/lib/weewx/weewx.sdb # Start the 
daemonsudosystemctlstartweewx
But seems it does not reflect my selected meteo station and keeps 
using Simulation.


The same with skin which I try to change in*etc/weewx/weewx.conf *but 
it does not reflect anything.


I'm sorry for these questions, your support is very helpful.
On Tuesday, March 19, 2024 at 11:58:18 PM UTC+1 Sidney wrote:

I do follow now. Thank you for the explanation. I'm now trying to
install a web server to get the page load on the local network.
Let's see whats next then. Thanks again.

On Tuesday, March 19, 2024 at 11:54:09 PM UTC+1 Rainer Lang wrote:

@Sidney - I think you are confusing a few things and are
comparing apples with pears.
You may not be aware of the functionality of and the need to
have a webserver (program).
CumulusMX has an inbuilt webserver, but not one which is
available to users other than the CMX users.
So when you can reach CMX via a defined port and the URL of
your weewx server e.g. IP:8998 this doesn't mean that a
generally available webserver is installed.

So, as Vince already mentioned, a webserver like nginx or
apache2 needs to be installed for you to see the weewx skin
via a browser via the URL.
You can of course open /var/www/html/weewx/index.html in a web
browser by loading it into the browser, but to reach it via
the URL ip-address/weewx a webserver is needed which has
access to the html-root (default /var/www/html) and
subdirectories and replies to your http request.

On 19.03.2024 23:43, Sidney wrote:

Thank you, Vince.
Seems I'm a bit lost in it and will be exploring it to find
the trouble.

On Tuesday, March 19, 2024 at 10:57:24 PM UTC+1 vince wrote:

You didn't provide enough detail to really understand
your setup.   Does Cumulus MX have some software it runs
that responds on port 8998 ?

Did you even install a normal webserver such as nginx or
apache ?   If not, see the wiki (link)

<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
 for
how to do install one and hook it together with weewx.

On Tuesday, March 19, 2024 at 1:23:58 PM UTC-7 Sidney wrote:

Thank you for a quick response. web server is for
sure installed as I do see Cumulus web server:
Screenshot 2024-03-19 at 21.20.46.png
When I try to go to http://192.168.0.40/weewx I'm
getting  This site can’t be reached. Sorry for
probably a silly question. Appreciate your support.
THank you.

On Tuesday, March 19, 2024 at 9:12:41 PM UTC+1 Rainer
    Lang wrote:

correct, but weewx (its Seasons skin) doesn't
have a realtime dashboard (except you install the
mqtt based Belchertown skin).
The update interval is defined in weewx.conf and
could go down to one minute instead of five
minutes (in theory - in practice to be found out
if the reports can complete in that short time)

On 19.03.2024 21:07, Sidney wrote:

And for example, when I want to view my
CumulusMX Dashboard, I call for:
"http://192.168.0.40:8998/;
<http://192.168.0.40:8998/>

On Tuesday, March 19, 2024 at 9:06:32 PM UTC+1
Sidney wrote:

Hi, I believe I've successfully installed
weewx. The manual says:

After about 5 minutes (the exact length of
time depends on your archiv

Re: [weewx-user] WS3500 - Only getting Station Name and Time/Date ???

2024-03-19 Thread 'Rainer Lang' via weewx-user

Normally, if all the rules are followed, weewx reading data from a
WH2910 console via interceptor driver is straightforward.

But who knows how you have configured your console and weewx.
Therefore the weewx.conf and customized server entry screenshot is needed.

Apart from that, I recommend to upgrade your WS3500 WiFi firmware to the
latest version 1.6.7 - version 1.5.2 is stone-age.
When you click on the device list entry in the WS View Plus app, a
firmware upgrade should be offered.

On 19.03.2024 21:33, Stefano wrote:

Hi,

Let me have a look tomorrow evening so in approx 24h I hope...

It is a Sainlogic WS3500 .

Thank you for your help.

On Tue, Mar 19, 2024, 21:23 'Rainer Lang' via weewx-user
wrote:

can you post your weewx.conf entries of the [Interceptor] stanza ?
Also a screecopy of your WS View Plus customized server entries
would be helpful.

I have just run out of my crystal balls ...
And a WS3500 is what ? A Sainlogic WS3500, an Ecowitt WH2910 clone ?
The more precise you are in your statements, the better we can
understand your point.

On 19.03.2024 21:17, Stefano wrote:

Hello,

Anybody facing something similar ? I'm only getting "unrecognized
parameter b'mac: '" and "unrecognized parameter
fields=timezone,utc_offset,dst,date_sunrise,date_sunset'",
"ignored parameter stationtype=EasyWeatherV1.5.2".

Thank you for your help.

On Tue, Mar 12, 2024 at 10:33 PM silverstone777
wrote:

I struggled a bit with the initial setup, but I finally
managed to get a custom Docker/Podman image running
(https://github.com/felddy/weewx-docker/ did NOT work for me).

After all of the struggle, I am now at a point where I am
getting *some* data, but *none* of the actual useful stuff. I
am only getting Station Name and Time/Data, but no actual
sensor data.

Basically what I'm getting is limited to this
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: POST:

b'mac=E8:DB:84:E4:92:6C=EasyWeatherV1.5.2=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: raw data:

b'mac=E8:DB:84:E4:92:6C=EasyWeatherV1.5.2=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] INFO user.interceptor: unrecognized
parameter b'mac=E8:DB:84:E4:92:6C
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: ignored
parameter stationtype=EasyWeatherV1.5.2
Mar 12 20:47:25 weewx[4] INFO user.interceptor: unrecognized
parameter
fields=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: raw packet:
{'dateTime': 1710276445, 'usUnits': 1}
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: mapped
packet: {'dateTime': 1710276445, 'usUnits': 1}

Some of the error messages are generated while I tried to
access the built-in webserver, although the webpage always
returns:
{"errcode":"0","errmsg":"ok","UTC_offset":"-18000"}

Is this a known issue or lack of configuration ?
weewx version 4.10.2

In the WSView Plus app I setup the System to use Ecowitt
Custom Protocol, my Server IP Address as well as the Port
8080. I am NOT sure however if the PATH is correct (I left
the default value). Should I have removed everything and left
the PATH blank in the WSView Plus app ?

Thank you for your help :).

--
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/407d41da-fa7f-4b74-8561-86d280bfb875n%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/407d41da-fa7f-4b74-8561-86d280bfb875n%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/CANhf2e7h9Yo%3D1EUYt8Tp8NY8a_igrrGcbcqoXsY2j1yWy6tKuQ%40mail.gmail.com

<https://groups.google.com/d/msgid/weewx-user/CANhf2e7h9Yo%3D1EUYt8Tp8NY8a_igrrGcbcqoXsY2j1yWy6tKuQ%40mail.gmail.com?utm_medium=email_source=footer>.
--
You received this message because you are subscribed to the Google

Groups "weewx-user" group.
To unsubscribe from this group and stop

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user

@Sidney - I think you are confusing a few things and are comparing
apples with pears.
You may not be aware of the functionality of and the need to have a
webserver (program).
CumulusMX has an inbuilt webserver, but not one which is available to
users other than the CMX users.
So when you can reach CMX via a defined port and the URL of your weewx
server e.g. IP:8998 this doesn't mean that a generally available
webserver is installed.

So, as Vince already mentioned, a webserver like nginx or apache2 needs
to be installed for you to see the weewx skin via a browser via the URL.
You can of course open /var/www/html/weewx/index.html in a web browser
by loading it into the browser, but to reach it via the URL
ip-address/weewx a webserver is needed which has access to the html-root
(default /var/www/html) and subdirectories and replies to your http request.

On 19.03.2024 23:43, Sidney wrote:

Thank you, Vince.
Seems I'm a bit lost in it and will be exploring it to find the trouble.

On Tuesday, March 19, 2024 at 10:57:24 PM UTC+1 vince wrote:

You didn't provide enough detail to really understand your setup.
Does Cumulus MX have some software it runs that responds on port
8998 ?

Did you even install a normal webserver such as nginx or apache ?
If not, see the wiki (link)

<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>
for
how to do install one and hook it together with weewx.

On Tuesday, March 19, 2024 at 1:23:58 PM UTC-7 Sidney wrote:

Thank you for a quick response. web server is for sure
installed as I do see Cumulus web server:
Screenshot 2024-03-19 at 21.20.46.png
When I try to go to http://192.168.0.40/weewx I'm
getting This site can’t be reached. Sorry for probably a
silly question. Appreciate your support. THank you.

On Tuesday, March 19, 2024 at 9:12:41 PM UTC+1 Rainer Lang wrote:

correct, but weewx (its Seasons skin) doesn't have a
realtime dashboard (except you install the mqtt based
Belchertown skin).
The update interval is defined in weewx.conf and could go
down to one minute instead of five minutes (in theory - in
practice to be found out if the reports can complete in
that short time)

On 19.03.2024 21:07, Sidney wrote:

And for example, when I want to view my CumulusMX
Dashboard, I call for: "http://192.168.0.40:8998/;
<http://192.168.0.40:8998/>

On Tuesday, March 19, 2024 at 9:06:32 PM UTC+1 Sidney wrote:

Hi, I believe I've successfully installed weewx. The
manual says:

After about 5 minutes (the exact length of time
depends on your archive interval), copy the following
and paste into a web browser. You should see your
station information and data.

/var/www/html/weewx/index.html
Can anyone help me how to call for this index from
another computer on the same network? I'm connected
to my Raspberry over SSH and cannot open the browser
there. Thank you.
Screenshot 2024-03-19 at 21.03.34.png

On Sunday, March 17, 2024 at 8:09:30 PM UTC+1 Sidney
wrote:

Hi, I would love to switch from Cumulus MX
template to weewx. How can I become a tester to
get the latest installation files please? Thank
you. Sidney

--
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/559472bb-05d0-419b-a38e-0a6d2331596dn%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/559472bb-05d0-419b-a38e-0a6d2331596dn%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/75cbe7d3-f1e3-438a-b482-ec508129ac82n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/75cbe7d3-f1e3-438a-b482-ec508129ac82n%40googlegroups.com?utm_medium=email_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

Re: [weewx-user] WS3500 - Only getting Station Name and Time/Date ???

2024-03-19 Thread 'Rainer Lang' via weewx-user

can you post your weewx.conf entries of the [Interceptor] stanza ?
Also a screecopy of your WS View Plus customized server entries would be
helpful.

I have just run out of my crystal balls ...
And a WS3500 is what ? A Sainlogic WS3500, an Ecowitt WH2910 clone ?
The more precise you are in your statements, the better we can
understand your point.

On 19.03.2024 21:17, Stefano wrote:

Hello,

Anybody facing something similar ? I'm only getting "unrecognized
parameter b'mac: '" and "unrecognized parameter
fields=timezone,utc_offset,dst,date_sunrise,date_sunset'", "ignored
parameter stationtype=EasyWeatherV1.5.2".

Thank you for your help.

On Tue, Mar 12, 2024 at 10:33 PM silverstone777
wrote:

I struggled a bit with the initial setup, but I finally managed to
get a custom Docker/Podman image running
(https://github.com/felddy/weewx-docker/ did NOT work for me).

After all of the struggle, I am now at a point where I am getting
*some* data, but *none* of the actual useful stuff. I am only
getting Station Name and Time/Data, but no actual sensor data.

Basically what I'm getting is limited to this
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: POST:

b'mac=E8:DB:84:E4:92:6C=EasyWeatherV1.5.2=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: raw data:

b'mac=E8:DB:84:E4:92:6C=EasyWeatherV1.5.2=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] INFO user.interceptor: unrecognized
parameter b'mac=E8:DB:84:E4:92:6C
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: ignored parameter
stationtype=EasyWeatherV1.5.2
Mar 12 20:47:25 weewx[4] INFO user.interceptor: unrecognized
parameter fields=timezone,utc_offset,dst,date_sunrise,date_sunset'
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: raw packet:
{'dateTime': 1710276445, 'usUnits': 1}
Mar 12 20:47:25 weewx[4] DEBUG user.interceptor: mapped packet:
{'dateTime': 1710276445, 'usUnits': 1}

Some of the error messages are generated while I tried to access
the built-in webserver, although the webpage always returns:
{"errcode":"0","errmsg":"ok","UTC_offset":"-18000"}

Is this a known issue or lack of configuration ?
weewx version 4.10.2

In the WSView Plus app I setup the System to use Ecowitt Custom
Protocol, my Server IP Address as well as the Port 8080. I am NOT
sure however if the PATH is correct (I left the default value).
Should I have removed everything and left the PATH blank in the
WSView Plus app ?

Thank you for your help :).

--
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/407d41da-fa7f-4b74-8561-86d280bfb875n%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/CANhf2e7h9Yo%3D1EUYt8Tp8NY8a_igrrGcbcqoXsY2j1yWy6tKuQ%40mail.gmail.com
.

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user

correct, but weewx (its Seasons skin) doesn't have a realtime dashboard
(except you install the mqtt based Belchertown skin).
The update interval is defined in weewx.conf and could go down to one
minute instead of five minutes (in theory - in practice to be found out
if the reports can complete in that short time)

On 19.03.2024 21:07, Sidney wrote:
And for example, when I want to view my CumulusMX Dashboard, I call
for: "http://192.168.0.40:8998/;

On Tuesday, March 19, 2024 at 9:06:32 PM UTC+1 Sidney wrote:

Hi, I believe I've successfully installed weewx. The manual says:

After about 5 minutes (the exact length of time depends on your
archive interval), copy the following and paste into a web
browser. You should see your station information and data.

/var/www/html/weewx/index.html
Can anyone help me how to call for this index from another
computer on the same network? I'm connected to my Raspberry over
SSH and cannot open the browser there. Thank you.
Screenshot 2024-03-19 at 21.03.34.png

On Sunday, March 17, 2024 at 8:09:30 PM UTC+1 Sidney wrote:

Hi, I would love to switch from Cumulus MX template to weewx.
How can I become a tester to get the latest installation files
please? Thank you. Sidney

Re: [weewx-user] Re: Cumulus MX -> weewx

2024-03-19 Thread 'Rainer Lang' via weewx-user

if you have a webserver installed, entering
http://ip-address-of-the-weewx-server/weewx will show you the last
created Seasons skin

On 19.03.2024 21:06, Sidney wrote:

Hi, I believe I've successfully installed weewx. The manual says:

After about 5 minutes (the exact length of time depends on your
archive interval), copy the following and paste into a web browser.
You should see your station information and data.

/var/www/html/weewx/index.html
Can anyone help me how to call for this index from another computer on
the same network? I'm connected to my Raspberry over SSH and cannot
open the browser there. Thank you.

Screenshot 2024-03-19 at 21.03.34.png

On Sunday, March 17, 2024 at 8:09:30 PM UTC+1 Sidney wrote:

Hi, I would love to switch from Cumulus MX template to weewx. How
can I become a tester to get the latest installation files please?
Thank you. Sidney

Re: [weewx-user] Ventus W830 or Ecowitt GW2000 help for Raspberry Pi

2024-03-18 Thread 'Rainer Lang' via weewx-user

@vince
for his GW2000 yes, but for his W830 no - the W830 doesn't have the
local Ecowitt API - there only the interceptor works (and quite well)

On 18.03.2024 21:59, vince wrote:
FWIW the gw1000 driver is 'much' easier to get going especially if
you're new to the pi. Works great.

On Monday, March 18, 2024 at 1:12:19 PM UTC-7 Pi Radio wrote:

Interceptor... I saw that earlier?

Going forwards I'll stop running and walk slowly through this.
Thank you.

By the way the Clock on my VHS VCR is still Flashing... I must
read the Instruction Manual one day. (If you are not of a certain
age, you are not going to get that joke).

But in all seriousness, I am struggling a bit finding my way
around all of this jargon, so I thought that before getting too
much further lost, I thought I'd wave and ask for guidance.

I've learnt a great deal so far on this massive learning curve,
but obviously I am not up to this ...yet.

Bear with me whilst I uninstall it all again, and start a fresh again.

Many thanks for the Links, I'm off to do some more reading.

On Mon, Mar 18, 2024 at 7:55 PM 'Rainer Lang' via weewx-user
wrote:

The Ventus W830 is a Ecowitt WH2910 clone. In your mail it is
not clear what "it" means. Your RaspberryPi, weewx, the
console ?
Maybe you should first make yourself familiar with your
environment, your setup, the architecture and then see where
weewx comes into play.

I suggest you read
https://www.wxforum.net/index.php?topic=40730.0 and read the
Ecowitt/FineOffset WiKi linked therein.
Read the chapters about data flow and understand where weewx
comes into play.
Then there are several chapters about how to connect an
Ecowitt console to data logger programs like weewx - even with
the special example of weewx.

For your W830 you can (only) use the weewx interceptor driver,
for your GW2000 the Ecowitt gateway driver aka GW1000 driver.

The weewx WiKi, even though having significantly improved over
time, does not give too much attention to the Ecowitt universe
yet.
But there is the Fine Offset / Ecowitt WiKi which jumps in
here regarding which Ecowitt (clone) consoles are supported.
The weewx WiKi itself is still widely focused on old legacy
models of Fine Offset clone consoles and stations.

So, I suggest you read this first (see above) and then come
back here if still needed - by the way, the Simulator driver
is only to show that weewx has been set up properly in
principle. It won't work with your console (Weather Station).
Having read the weewx documentation you could have understood
that - but to be fair, it took me also a longer time to come
to grips with the jargon etc. used even though being an IT
professional.

On 18.03.2024 20:15, Pi Radio wrote:

I have just joined, and cannot get my Raspberry Pi configured
for my Ventus W830 PWS. It is linked to various Online
Weather sites including Weather Underground via it's Display.
I also have it linked to an Ecowitt GW2000 that is not
currently linked to any Online Weather sites.

I have read the User Guide, and followed various Tutorials,
but I am none the wiser as to why it does not work?

Is there a step by step guide that is written for a complete
novice like me to follow?

Although the Ventus W830 is listed in the Compatible Hardware
List as a Fine Offset model it does not appear in the
Available Hardware Types in the Software on my Raspberry Pi.
I have tried using Simulator, plus all of the (dozen or so)
options for the various types of PWS listed in the software.

What am I not doing correctly, or what I have missed, I have
no idea? I have just followed the Instructions in the
"Guide". But there still seem to be lots of CRITICAL
__main__: errors in Red, so it is a bit catistrophic?

I am not a programmer, nor that familiar with a Raspberry Pi.
All I know is what I have been struggling with here, and
following YouTube videos.

Any help would be very, very much appreciated.
--
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/b6dde367-1685-40a0-a908-8050ccbe9e86n%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/b6dde367-1685-40a0-a908-8050ccbe9e86n%40googlegroups.com?utm_medium=email_source

Re: [weewx-user] Ventus W830 or Ecowitt GW2000 help for Raspberry Pi

2024-03-18 Thread 'Rainer Lang' via weewx-user

The Ventus W830 is a Ecowitt WH2910 clone. In your mail it is not clear
what "it" means. Your RaspberryPi, weewx, the console ?
Maybe you should first make yourself familiar with your environment,
your setup, the architecture and then see where weewx comes into play.

I suggest you read https://www.wxforum.net/index.php?topic=40730.0 and
read the Ecowitt/FineOffset WiKi linked therein.
Read the chapters about data flow and understand where weewx comes into
play.
Then there are several chapters about how to connect an Ecowitt console
to data logger programs like weewx - even with the special example of weewx.

For your W830 you can (only) use the weewx interceptor driver, for your
GW2000 the Ecowitt gateway driver aka GW1000 driver.

The weewx WiKi, even though having significantly improved over time,
does not give too much attention to the Ecowitt universe yet.
But there is the Fine Offset / Ecowitt WiKi which jumps in here
regarding which Ecowitt (clone) consoles are supported.
The weewx WiKi itself is still widely focused on old legacy models of
Fine Offset clone consoles and stations.

So, I suggest you read this first (see above) and then come back here if
still needed - by the way, the Simulator driver is only to show that
weewx has been set up properly in principle. It won't work with your
console (Weather Station). Having read the weewx documentation you could
have understood that - but to be fair, it took me also a longer time to
come to grips with the jargon etc. used even though being an IT
professional.

On 18.03.2024 20:15, Pi Radio wrote:
I have just joined, and cannot get my Raspberry Pi configured for my
Ventus W830 PWS. It is linked to various Online Weather sites
including Weather Underground via it's Display. I also have it linked
to an Ecowitt GW2000 that is not currently linked to any Online
Weather sites.

I have read the User Guide, and followed various Tutorials, but I am
none the wiser as to why it does not work?

Is there a step by step guide that is written for a complete novice
like me to follow?

Although the Ventus W830 is listed in the Compatible Hardware List as
a Fine Offset model it does not appear in the Available Hardware Types
in the Software on my Raspberry Pi. I have tried using Simulator, plus
all of the (dozen or so) options for the various types of PWS listed
in the software.

What am I not doing correctly, or what I have missed, I have no idea?
I have just followed the Instructions in the "Guide". But there still
seem to be lots of CRITICAL __main__: errors in Red, so it is a bit
catistrophic?

I am not a programmer, nor that familiar with a Raspberry Pi. All I
know is what I have been struggling with here, and following YouTube
videos.

Any help would be very, very much appreciated.
--
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/b6dde367-1685-40a0-a908-8050ccbe9e86n%40googlegroups.com
.

Re: [weewx-user] Ecowitt lightning sensor WH57

2024-03-14 Thread 'Rainer Lang' via weewx-user


a lighter, the flash of a camera in front of the sensor 

On 14.03.2024 18:50, Joachim Puttkammer wrote:

How can I simulate lightning for the WH57 sensor?
--
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/9689547b-9855-4e8d-acfb-b89c38aa690en%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/758ecc14-0d81-4774-9d00-00823a19c325%40gmail.com.

Re: [weewx-user] Making a backup of the SQLite database

2024-02-05 Thread 'Rainer Lang' via weewx-user


I don't think it has changed ... why would it ?
It's a reasonable approach for how and when to copy an active database. 
That's independent of the weewx version.
Safest way is always to shutdown weewx (best immediately after the last 
archive records were written), then copy, then restart weewx


On 05.02.2024 09:58, Joachim Puttkammer wrote:

Are the instructions from the user's guide still up to date?
"Do not make the copy of the SQLite database while in the middle of a 
transaction! Schedule the backup for immediately after an archive 
record is written, and then make sure the backup completes before the 
next archive record arrives. Alternatively, stop WeeWX, perform the 
backup, then restart WeeWX."

--
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/612bb503-dcfa-4e55-8df3-3524422a517fn%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/82f63e98-9122-4280-8b17-2e7f1c968e79%40gmail.com.

Re: [weewx-user] interceptor stops my station

2023-12-16 Thread 'Rainer Lang' via weewx-user

interesting, but as you didn't give us more context, you're likely not 
to receive a satisfactory reply


1. it is good practice to post a _*complete*_ syslog protocol from a 
weewx start to at least one archiving and reporting cycle (unless it 
doesn't reach it)
2. you should tell us about your context - what weather station are you 
talking about, what console do you use, did you change anything in your 
console (added a sensor, changed a configuration etc.)


without that you expect us reading a crystal ball - what we are not 
proficient in


On 14.12.2023 21:22, enu...@gmail.com wrote:

today, i got this error
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__: Caught 
unrecoverable exception:
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:  
 'totalrainin'
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:  
 Traceback (most recent call last):
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:     File 
"/usr/share/weewx/weewxd", line 154, in main
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:      
 engine.run()
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:     File 
"/usr/share/weewx/weewx/engine.py", line 208, in run
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:      
 for packet in self.console.genLoopPackets():
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:     File 
"/usr/share/weewx/user/interceptor.py", line 2558, in genLoopPackets
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:      
 pkt = self._device.parser.parse(data)
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:     File 
"/usr/share/weewx/user/interceptor.py", line 2398, in parse
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:      
 self.LABEL_MAP.pop('totalrainin')
Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:  
 KeyError: 'totalrainin'

Dec 14 15:32:57 raspberrypi weewx[756] CRITICAL __main__:   Exiting.
I don't know because sudendly stop weewx and i had reset it hours later.
--
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/5e0bacdf-f9f4-4af5-b7d1-079cec62eefdn%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/8dc1ba54-e80f-421a-92f5-7eb1847baf0c%40gmail.com.

Re: [weewx-user] ERROR unecpecteddevice id

2023-12-11 Thread 'Rainer Lang' via weewx-user

that's the weexwx end - but to me this looks like an issue at the 
console end.
Each transceiver stick has a unique ID which should be mentioned in 
weewx.conf

(and which will be reported in the syslog, when debug = 1)
Also the console needs to be paired with the transceiver stick - that's 
KlimaLogg manual.
You may have selected the wrong logger in the console - then the weewx 
extension will not recognize the transceiver


On 11.12.2023 19:57, BORIS wrote:

Hello Rainer,
/Did you press the USB button for the console to initiate the 
communication while weewx was waiting ?  Yes
Did you choose the proper Logger in the console ? I am not sure what 
you mean with that./

*I followed the instruction for installation as given from:*
Platform Packages

For Debian, Ubuntu, Mint, including Raspberry Pi, see:
http://weewx.com/docs/debian.htm

I cannot access the installation now and will provide more detailed 
log later with debug set to 1.
I may have forgotten to add the Klimalogg installation at GitHub - 
matthewwall/weewx-klimalogg: klimalogg pro driver for weewx 
<https://github.com/matthewwall/weewx-klimalogg>

/Boris
måndag 11 december 2023 kl. 17:03:56 UTC+1 skrev Rainer Lang:

only from the context (and when you know) one can guess that you
are talking about KlimaLogg and the the KlimaLogg extension.
And the messages refer to the tranceiver USB stick through which
the KlimaLogg console communicates with weewx
Are you aware of how the two devices cooperate ?

Did you press the USB button for the console to initiate the
communication while weewx was waiting ?
Did you choose the proper Logger in the console ?
That doesn't look like a weewx issue but a user issue handling
their hardware 
what does the [kl] stanza in your weewx.conf look like ?

Normally we reply here only if you provide a log from a new start
of weewx - and from the start of the logging
such snippets are not helpful - most likely, provided you have set
debug = 1 or debug = 3 in weewx.conf and restarted,
in the earlier syslog messages at startup some hints can be found

providing such a complete log has the chance to be more insightful
- looking forward to seeing it ...

On 11.12.2023 16:29, BORIS wrote:

When starting a new installation I get the following error.

boris@boris-NUC-Jamjo:~$ sudo tail -f /var/log/syslog
Dec 11 16:21:16 boris-NUC-Jamjo weewx[770] INFO user.kl: press
the USB button to start communication
Dec 11 16:21:28 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject
scan trigger since one is already pending
Dec 11 16:21:28 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed
to initiate AP scan
Dec 11 16:21:29 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject
scan trigger since one is already pending
Dec 11 16:21:29 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed
to initiate AP scan
Dec 11 16:21:30 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject
scan trigger since one is already pending
Dec 11 16:21:30 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed
to initiate AP scan
Dec 11 16:21:31 boris-NUC-Jamjo weewx[770] INFO user.kl: press
the USB button to start communication
Dec 11 16:21:46 boris-NUC-Jamjo weewx[770] INFO user.kl: press
the USB button to start communication
Dec 11 16:22:01 boris-NUC-Jamjo weewx[770] INFO user.kl: press
the USB button to start communication
Dec 11 16:22:16 boris-NUC-Jamjo weewx[770] INFO user.kl: press
the USB button to start communication
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
generateResponse: intercepted message from device 01bd with
length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
unexpected device ID (id=01bd); use parameter 'serial' if more
than one USB transceiver present
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
generateResponse: intercepted message from device 01bd with
length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
unexpected device ID (id=01bd); use parameter 'serial' if more
than one USB transceiver present
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
generateResponse: intercepted message from device 01bd with
length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl:
unexpected device ID (id=01bd); use parameter 'serial' if more
than one USB transceiver present
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl:
generateResponse: intercepted message from device 01bd with
length: e5
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl:
unexpected device ID (id=01bd); use parameter 'serial' if more
than one USB transceiver present
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl:
generateResponse: intercepted message from device 01bd with
length: e5
Dec 11 16:22:24 boris-NUC-Jamjo wee

Re: [weewx-user] ERROR unecpecteddevice id

2023-12-11 Thread 'Rainer Lang' via weewx-user

only from the context (and when you know) one can guess that you are 
talking about KlimaLogg and the the KlimaLogg extension.
And the messages refer to the tranceiver USB stick through which the 
KlimaLogg console communicates with weewx

Are you aware of how the two devices cooperate ?

Did you press the USB button for the console to initiate the 
communication while weewx was waiting ?

Did you choose the proper Logger in the console ?
That doesn't look like a weewx issue but a user issue handling their 
hardware 

what does the [kl] stanza in your weewx.conf look like ?

Normally we reply here only if you provide a log from a new start of 
weewx - and from the start of the logging
such snippets are not helpful - most likely, provided you have set debug 
= 1 or debug = 3 in weewx.conf and restarted,

in the earlier syslog messages at startup some hints can be found

providing such a complete log has the chance to be more insightful - 
looking forward to seeing it ...


On 11.12.2023 16:29, BORIS wrote:

When starting a new installation I get the following error.

boris@boris-NUC-Jamjo:~$ sudo tail -f /var/log/syslog
Dec 11 16:21:16 boris-NUC-Jamjo weewx[770] INFO user.kl: press the USB 
button to start communication
Dec 11 16:21:28 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject scan 
trigger since one is already pending
Dec 11 16:21:28 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed to 
initiate AP scan
Dec 11 16:21:29 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject scan 
trigger since one is already pending
Dec 11 16:21:29 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed to 
initiate AP scan
Dec 11 16:21:30 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Reject scan 
trigger since one is already pending
Dec 11 16:21:30 boris-NUC-Jamjo wpa_supplicant[638]: wlo2: Failed to 
initiate AP scan
Dec 11 16:21:31 boris-NUC-Jamjo weewx[770] INFO user.kl: press the USB 
button to start communication
Dec 11 16:21:46 boris-NUC-Jamjo weewx[770] INFO user.kl: press the USB 
button to start communication
Dec 11 16:22:01 boris-NUC-Jamjo weewx[770] INFO user.kl: press the USB 
button to start communication
Dec 11 16:22:16 boris-NUC-Jamjo weewx[770] INFO user.kl: press the USB 
button to start communication
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:23 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:24 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present
Dec 11 16:22:25 boris-NUC-Jamjo weewx[770] ERROR user.kl: 
generateResponse: intercepted message from device 01bd with length: e5
Dec 11 16:22:25 boris-NUC-Jamjo weewx[770] ERROR user.kl: unexpected 
device ID (id=01bd); use parameter 'serial' if more than one USB 
transceiver present


What is wrong?
/Boris
--
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/e098085b-7b58-44b6-b0d3-fd740edd6d7en%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

Re: [weewx-user] Re: Weewx running but interceptor not capturing data?

2023-12-08 Thread 'Rainer Lang' via weewx-user

you may have to have your console post its data also via the customized 
server functionality to your RPi, using Wunderground protocol, and e.g. 
port 8000
and then have your interceptor driver at the weewx end listen at port 
8000. Mode would then be listening and not sniffing ! wu-client to be 
chosen as device

(weewx.conf [Interceptor] stanza)
You can also first try to run the driver stand-alone as described in the 
READ.ME on GitHub


On 08.12.2023 05:18, vince wrote:
In the absence of you providing any config file(s) nor debug=1 logs 
nope no ideas other than trying dropping shields and running with no 
firewall if you can do that safely on your network.


On Thursday, December 7, 2023 at 6:16:59 PM UTC-8 Mark Sanchez wrote:

Hello,
I have now wasted four days so far trying to get weewx setup with
my Ambient WS-2902 using interceptor to sniff the packets as it's
headed to Ambient Weather's site. I believe I have it running at
this point and Apache is set up but nothing is going into the
specified folder. How can I tell if it's sniffing the data or not?

thechez@raspberrypi:~ $ service weewx status
● weewx.service - LSB: weewx weather system
     Loaded: loaded (/etc/init.d/weewx; generated)
     Active: active (running) since Thu 2023-12-07 18:12:50 PST;
55s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 433 ExecStart=/etc/init.d/weewx start (code=exited,
status=0/SUCCESS)
      Tasks: 2 (limit: 1595)
        CPU: 1.314s
     CGroup: /system.slice/weewx.service
             └─657 python3 /usr/share/weewx/weewxd --daemon
--pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf

Dec 07 18:12:50 raspberrypi python3[657]: weewx[657] INFO
weewx.restx: PWSweather: Posting not enabled.
Dec 07 18:12:50 raspberrypi python3[657]: weewx[657] INFO
weewx.restx: CWOP: Posting not enabled.
Dec 07 18:12:50 raspberrypi python3[657]: weewx[657] INFO
weewx.restx: WOW: Posting not enabled.
Dec 07 18:12:50 raspberrypi python3[657]: weewx[657] INFO
weewx.restx: AWEKAS: Posting not enabled.
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
weewx.engine: 'pyephem' detected, extended almanac data is available
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
__main__: Starting up weewx version 4.10.2
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
weewx.engine: Using binding 'wx_binding' to database 'weewx.sdb'
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
weewx.manager: Starting backfill of daily summaries
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
weewx.manager: Daily summaries up to date
Dec 07 18:12:51 raspberrypi python3[657]: weewx[657] INFO
weewx.engine: Starting main packet loop.

I have changed my iptables to capture the local IP and port but it
doesn't seem to be doing anything. Any ideas or any more
information I could add?
Thanks.

--
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/4430080d-6325-4e91-a97a-e02b1d9eb47cn%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/c8618e39-505e-491d-bc24-d7543a277b51%40gmail.com.

Re: [weewx-user] Advice on new installation

2023-12-07 Thread 'Rainer Lang' via weewx-user

someone needs to add the existing backfill possibility which CumulusMX
already uses to an existing driver (Ecowitt Gateway and/or interceptor)
- i.e.
when an Ecowitt clone console posts to ecowitt.net (need account and
console registered), using the MAC address of the console and a
to-be-created APP-key and API-key one can retrieve this data on a
5-minute resolution for up to 90 days back by a http call to the ecowitt
cloud API - see also https://www.wxforum.net/index.php?topic=40730

maybe an inspiration for Gary to include this functionality into his
local Ecowitt Gateway driver as an option to backfill. 

I'm astonished that CumulusMX is the only weather software so far (known
to me) which uses this possibility.
I'm sure many users of the local Ecowitt Gateway driver (GW1000 driver)
would appreciate such a functionality upgrade.

I have other mechanisms in place to fill these gaps - e.g. mirror
installations etc. including using the CumulusMX database files running
CMX in parallel and then do the manual backfill with wee_import;
that's a maximum semi-automated solution; however, a fully automated
approach for weewx jumping in at restart when a gap is detected would be
definitely much better

On 07.12.2023 14:22, 'michael.k...@gmx.at' via weewx-user wrote:
I asked more or less the same question as Keith and I am quite happy
with Rainer's recommendation (which I followed). The only thing left
to make me more than happy, is to find an automatic way to backfill
missing sensor data for the rare occasions, weewx isn't running for
whatever reason. The 23xx did this, when you restartet weewx (if the
built in memory was sufficient).

Keith Jacobs schrieb am Donnerstag, 7. Dezember 2023 um 13:00:13 UTC+1:

Thanks for that, very useful.

I guess what I meant by 'compatible' was the "Supported Hardware"
list on https://weewx.com/hardware.html, almost all of which
appear unobtainable.

On 07/12/2023 11:22, 'Rainer Lang' via weewx-user wrote:

Not sure what you mean by "compatible" here - but beyond Davis
there is a whole station/sensor/IoT universe

Have a look at https://www.ecowitt.com
and for a better understanding
https://www.wxforum.net/index.php?topic=40730
all these stations can be used with weewx with either the Ecowitt
local Gateway driver of the interceptor driver

On 07.12.2023 11:34, Keith Jacobs wrote:

My LeCross 23xx died after many years good service and would
like to use weewx with a new station. My problem is finding a
compatible weather station that can actually be bought new,
apart from there expensive Davis. All others are listed as obsolete
Thanks
--
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/0a82e1a4-73f2-4ee6-b919-b5fad039d636n%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/0a82e1a4-73f2-4ee6-b919-b5fad039d636n%40googlegroups.com?utm_medium=email_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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/bc3b3aff-e7d3-4646-9e41-c31daf4cfd5b%40gmail.com

<https://groups.google.com/d/msgid/weewx-user/bc3b3aff-e7d3-4646-9e41-c31daf4cfd5b%40gmail.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/8c40e71b-c469-4e84-9ad0-7124e892b473n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/8c40e71b-c469-4e84-9ad0-7124e892b473n%40googlegroups.com?utm_medium=email_source=footer>.

Re: [weewx-user] Advice on new installation

2023-12-07 Thread 'Rainer Lang' via weewx-user

Not sure what you mean by "compatible" here - but beyond Davis there is 
a whole station/sensor/IoT universe


Have a look at https://www.ecowitt.com
and for a better understanding
https://www.wxforum.net/index.php?topic=40730
all these stations can be used with weewx with either the Ecowitt local 
Gateway driver of the interceptor driver



On 07.12.2023 11:34, Keith Jacobs wrote:
My LeCross 23xx died after many years good service and would like to 
use weewx with a new station. My problem is finding a compatible 
weather station that can actually be bought new, apart from there 
expensive Davis. All others are listed as obsolete

Thanks
--
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/0a82e1a4-73f2-4ee6-b919-b5fad039d636n%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/bc3b3aff-e7d3-4646-9e41-c31daf4cfd5b%40gmail.com.

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-06 Thread 'Rainer Lang' via weewx-user


Hi Marlon

three more remarks:
1. comparing to neighbouring environment may not always be helpful - as 
rainfall is not a homogeneous phenomenon and 100 m away from your sensor 
there may even be no rainfall at all - or vice versa. A proper manual 
gauge close to your sensor makes more sense.


2. your WH65 arrray with its rain gauge may not be at the same height as 
your manual gauge ! To be considered.

Did you clean your rain gauge (WH65) properly ?

3. if you are looking for more accuracy:
get yourself a WH40 with a rim height extension 
(https://www.wxforum.net/index.php?topic=44074.0) and a GW1100 (or 
GW2000) as your WH2910 console (Froggit WH3000SE) cannot receive the 
WH40 - mount it at 1-1.5 m above ground and put your manual gauge close 
to it - same height.
Use a calibration factor of 1.02 for the WH40 - due to imperial/metric 
conversion.


And then you are much better set for your endeavours.

Your issue(s) is(are) in my opinion not weewx related but 
console/sensor/location related.


On 06.11.2023 08:18, Marlon wrote:

Thank you Rainer and Gary
The effortnis greatly appreciated and I will find a way to give back 
to weewx community for this.
There's a lot here on the last posts that have given me a lot of food 
for thought. Im going to have to launch a huge project here to find 
the way these other sites have created discrepancies and how I can fix 
that to get the data normalised.


The 824mm is the amount that matches my plastic guage and neighbouring 
farms, So it's the number I need to work towards.


Once I have that figured out, there's still the original question of 
whether the new events into wee will work after the interval change. 
Strangest thing is getting the same weirdness from Wu, weathercloud, 
ecowitt, etc. That does make the console sound guilty, but with that 
said, that number is most correct. Confusing.


But I'll then post the findings here, and possibly some code so that 
this thread can have the usefulness to others in the future.


Thank you
Marlon



On Monday, 06 November 2023 at 09:04:02 UTC+2 Rainer Lang wrote:

summary data shown on the ecowitt.net <http://ecowitt.net>
dashboard are the values from the console and can be changed by
the user in the console. At ecowitt.net <http://ecowitt.net> no
summarizing is done for the displayed tiles, just display of what
the console sends. What is shown there is user responsibility. If
the user makes adjustments, they are simply taken over and
displayed. => you can only conditionally expect accuracy in the
summary counts - it may or may not not match the really stored
5-minute (or longer period summarized data depending on the
retention policy) data. (we can see the discrepancies between
import summaries, NOAA summaries and dashboard tile summaries)

If there is a discrepancy between this summary data shown on the
dashboard tiles and the summarized end-of-day data for rain, this
is most likely user caused. (800+ vs. 470)
Data from the import was all properly stored - discrepancies are
likely to be user caused and not we_import caused.

On 06.11.2023 05:48, gjr80 wrote:

I have spent this morning working through the csv data, the NOAA
format reports on your web site and the data on Ecowitt.net.
There are a couple of issues going on. First, the bulk of the
difference between the Ecowitt.net yearly rainfall (presently
showing 824.1mm) and that imported by wee_import (approx 507mm)
is due to data inconsistencies on Ecowitt.net. The yearly
rainfall value displayed by Ecowitt.net is taken from the yearly
rain field (presumably uploaded by the station). If you look
through the 2023 tabulated data for the station on Ecowitt.net
you will see the yearly rainfall value was non-existent until 6
June when it took on the value 585.1mm, but if you sum the
monthly rainfall values from 1 January until 6 June you get
something of the order of 254mm (it is impossible to say exactly
due to discrepancies between the values in the various
Ecowitt.net rain fields). This accounts for some 330mm of the
difference. I have also found at least one place where the
Ecowitt.net rain data goes backwards (23 February 06:00 monthly
rainfall is 5.6mm, the 10:00 entry indicates 0.8mm fell taking
the monthly total to 6.6mm, the 14:00 entry shows no rain but the
monthly value jumps back to 5.6mm), whilst this may or may not
impact the import (it depends on how the import is setup) it begs
the question are there other data discrepancies that may impact
the import. I haven't yet checked for any other similar
discrepancies.

I have also noticed discrepancies in the NOAA format reports. For
some reason the 2023 report shows the March rainfall as 100.8mm,
whereas the March 2023 report shows a monthly total of 105.6mm.
The archive and daily summary tables both have 10

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-05 Thread 'Rainer Lang' via weewx-user

summary data shown on the ecowitt.net dashboard are the values from the 
console and can be changed by the user in the console. At ecowitt.net no 
summarizing is done for the displayed tiles, just display of what the 
console sends. What is shown there is user responsibility. If the user 
makes adjustments, they are simply taken over and displayed. => you can 
only conditionally expect accuracy in the summary counts - it may or may 
not not match the really stored 5-minute (or longer period summarized 
data depending on the retention policy) data. (we can see the 
discrepancies between import summaries, NOAA summaries and dashboard 
tile summaries)


If there is a discrepancy between this summary data shown on the 
dashboard tiles and the summarized end-of-day data for rain, this is 
most likely user caused. (800+ vs. 470)
Data from the import was all properly stored - discrepancies are likely 
to be user caused and not we_import caused.


On 06.11.2023 05:48, gjr80 wrote:
I have spent this morning working through the csv data, the NOAA 
format reports on your web site and the data on Ecowitt.net. There are 
a couple of issues going on. First, the bulk of the difference between 
the Ecowitt.net yearly rainfall (presently showing 824.1mm) and that 
imported by wee_import (approx 507mm) is due to data inconsistencies 
on Ecowitt.net. The yearly rainfall value displayed by Ecowitt.net is 
taken from the yearly rain field (presumably uploaded by the station). 
If you look through the 2023 tabulated data for the station on 
Ecowitt.net you will see the yearly rainfall value was non-existent 
until 6 June when it took on the value 585.1mm, but if you sum the 
monthly rainfall values from 1 January until 6 June you get something 
of the order of 254mm (it is impossible to say exactly due to 
discrepancies between the values in the various Ecowitt.net rain 
fields). This accounts for some 330mm of the difference. I have also 
found at least one place where the Ecowitt.net rain data goes 
backwards (23 February 06:00 monthly rainfall is 5.6mm, the 10:00 
entry indicates 0.8mm fell taking the monthly total to 6.6mm, the 
14:00 entry shows no rain but the monthly value jumps back to 5.6mm), 
whilst this may or may not impact the import (it depends on how the 
import is setup) it begs the question are there other data 
discrepancies that may impact the import. I haven't yet checked for 
any other similar discrepancies.


I have also noticed discrepancies in the NOAA format reports. For some 
reason the 2023 report shows the March rainfall as 100.8mm, whereas 
the March 2023 report shows a monthly total of 105.6mm. The archive 
and daily summary tables both have 105.6mm for March, but for some 
reason the monthly report is off. Ecowitt.net also shows 105.6mm for 
March. Similarly in October. The October 2023 report shows 28.4mm but 
the 2023 reports shows October with 27.1mm, the archive and daily 
summary tables both record 28.4mm. I will have to look at this 
further, but at present I would be wary of rainfall in the yearly NOAA 
reports; the monthly reports seem to show the true value.


So far I have not been able to fault wee_import.

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/dc17cabc-7722-4a27-ac6b-5f96ec306786n%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/7cac4bfc-afd1-4dcd-a57c-d1c741ddbdf3%40gmail.com.

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-05 Thread 'Rainer Lang' via weewx-user


I have no idea why it should be 800+ mm
I did the work deleting all 0.0 mm value records and left for non 0.0 
days only the last record (usually either 18:00 or 22:00 whatever was 
available)
and added them all up - result: 507.2 mm as opposite to the 470.2 mm 
shown in your graph and NOAA. Not 800+


PRECIPITATION (mm)

  MAX ---DAYS OF RAIN---
  OBS.   OVER
 YR  MO  TOTALDAY  DATE   0.30   3.00  30.00

2023 01   21.6   17.305  2  2  0
2023 026.32.820  6  0  0
2023 03  100.8   56.405  7  4  2
2023 04   13.04.622  5  3  0
2023 05  111.2   56.931 13  7  1
2023 06   79.4   22.615 15  5  0
2023 07   35.9   14.709 12  3  0
2023 086.62.023  5  0  0
2023 09   68.3   48.525  7  3  1
2023 10   27.1   11.421  5  4  0
2023 110.00.001  0  0  0
2023 12

 470.2   56.9   May 77 31  4

also, your NOAA reports are not consistent - e.g. sum Oct 23 in the yearly 
view: 27.1, in the Oct 23 monthly view: 23.9

Going through the import field map and the import  CSV file,I cannot see 
any reason where this (meanwhile as far as I could tell in a first rough 
check) only 35 mm difference comes from.


All these consistency checks you could have done yourself and come to 
the same results as I did, couldn't you ?
I attach the Excel file I created from your import.csv - the other 
columns are hidden (mark adjacent columns --> Format --> Hide/Unhide)
No guarantee I missed some lines - but you can repeat the approach - and 
make sure all your NOAA reports are consistent amongst each other in the 
first place.


As a practical/pragmatic approach I suggest you complete the Excel for 
each month - create an additional import file with a time stamp one 
minute later than the last one each month (using the other data from the 
last record) with the missing amount and import it
Or use sqlitebrowser as suggested earlier to add the missing values of 
the respective days to the day already imported.
When you use sqlitebrowser, you will need to update the daily summaries 
(wee_database)

In the end, at least you will have a consistent database.

If Gary or someone else has the time to analyze the data more deeply to 
figure out why wee_import does an incomplete job, they shall feel free 
to do so



On 05.11.2023 15:44, Marlon wrote:

Okie dokes.
I re-exported data from ecowitt. 4 hour intervals. I cleaned up the CSV
Then confirmed import conf is correct, confirmed row count ( | wc -l| 
and deleted my sqlite db so we can load from scratch.
Import seemed fine on dry run, so I launched import. Rain total is yet 
again, different. This time it is 470mm (still not the 800+ it should be).

Rain config set to cumulative (since ecowitt does not export yearly).

Sharing the new config, csv and logs as you requested. You should be 
able to compare now, Rainer.

Hope I can find a way to thank you and Gary for the help.

On Sunday, 05 November 2023 at 02:23:37 UTC+2 Rainer Lang wrote:

can you remove all lines with ";;" from the import CSV
file and start the import again (I assume you still have an
untouched copy of your database),
re-create the NOAA reports and check again ...
The NOAA reports from your web site is the only place where I
could compare the import file content with your web site database.
Obviously at certain days no data or not all data of that day were
imported.
Can you also provide the syslog from this import (or from your
last import) - maybe for certain timestamps already a record
existed and wee_import couldn't create this record again.
wee_import only creates new records - doesn't update existing
records !

On 04.11.2023 18:33, Marlon wrote:

Hi guys
Thanks, and apologies for a latent reply. Life got hold of me for
a while.
I ran the daily summaries and reweighting out of desperation, but
as you mentioned, they seemed to be done auto by wee_import

I am attaching the gzipped versions of the conf and csv. This
particular CSV is the latest attempt I made, and has 10 min
intervals (weather cloud). Previously I did the same with ecowitt
(but with their varying intervals).
Everything seems perfect, except rain - rain is wrong from either
sites (yet displayed correctly ON those sites). I will also share
the links to those if that helps to prove my sanity (or lack
thereof).
My WeeWX site: weewx.simple-earth.org
<http://weewx.simple-earth.org> (rain wrong).
My Station on Ecowitt www.ecowitt.net/home/index?id=68712
<http://www.ecowitt.net/home/index?id=68712> (rain shown
correctly and matching man

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-04 Thread 'Rainer Lang' via weewx-user

can you remove all lines with ";;" from the import CSV file 
and start the import again (I assume you still have an untouched copy of 
your database),

re-create the NOAA reports and check again ...
The NOAA reports from your web site is the only place where I could 
compare the import file content with your web site database.

Obviously at certain days no data or not all data of that day were imported.
Can you also provide the syslog from this import (or from your last 
import) - maybe for certain timestamps already a record existed and 
wee_import couldn't create this record again.

wee_import only creates new records - doesn't update existing records !

On 04.11.2023 18:33, Marlon wrote:

Hi guys
Thanks, and apologies for a latent reply. Life got hold of me for a while.
I ran the daily summaries and reweighting out of desperation, but as 
you mentioned, they seemed to be done auto by wee_import


I am attaching the gzipped versions of the conf and csv. This 
particular CSV is the latest attempt I made, and has 10 min intervals 
(weather cloud). Previously I did the same with ecowitt (but with 
their varying intervals).
Everything seems perfect, except rain - rain is wrong from either 
sites (yet displayed correctly ON those sites). I will also share the 
links to those if that helps to prove my sanity (or lack thereof).

My WeeWX site: weewx.simple-earth.org (rain wrong).
My Station on Ecowitt www.ecowitt.net/home/index?id=68712 (rain shown 
correctly and matching manual meters)


Thanks Gary and Rainer. Appreciated.
Marlon




On Thursday, 02 November 2023 at 06:59:31 UTC+2 gjr80 wrote:

On Thursday, 2 November 2023 at 02:46:03 UTC+10
lang@googlemail.com wrote:

1. as Gary (@gjr80) already mentioned - send us your
import.conf file for the CSV import and maybe 5 lines of your
import CSV file including the first line with the descriptors

No, please include the whole CSV file; if the issue is the
accuracy of the totals we are going to need to see all of the
source data, not just a few lines.

2. did you run the daily summary update after the import ?
sudo wee_database .. from=    to= (see wee_database --help)

There is no need to update the daily summaries after importing via
wee_import, wee_import automatically updates the daily summaries
once the data has been imported into the archive.

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/86c605c3-1b72-4c79-aad4-ff18bb97a7dcn%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/00d6653f-839a-4833-a1ec-047b05084a03%40gmail.com.

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-01 Thread 'Rainer Lang' via weewx-user

1. as Gary (@gjr80) already mentioned - send us your import.conf file 
for the CSV import and maybe 5 lines of your import CSV file including 
the first line with the descriptors


2. did you run the daily summary update after the import ?
sudo wee_database .. from=    to= (see wee_database --help)

3. did you compare the values from the import CSV file with what was 
written to the database ?
(download/install sqlitebrowser unless already installed and start it 
with "sudo sqlitebroswer /var/lib/weewx/weewx.sdb"
(or whatever is the path to your weewx database) and compare the added 
records:
convert your date/time stamp into EPOCH to find the corresponding record 
in the first database column)


On 01.11.2023 13:40, gjr80 wrote:
As I said earlier; post or email the data you are importing along with 
the import config file. The import process is deterministic and 
relatively straightforward to troubleshoot.


Gary

On Wednesday, 1 November 2023 at 22:00:35 UTC+10 marlo...@gmail.com wrote:

Reposting to clarify

Thank you Rainer, most helpful.

FWIW, I set the much longer archive, and got everything back to
standard.
I cannot test with rain, until it rains, but I did import data
from weathercloud, and the final result contains the same error.
Year total report is 401 (should be 829). Another example, October
reports 23.9mm, but the actual number is 28.4mm

I also previously imported from ecowitt, with the same problem.
EcoWitt and WeatherCloud have the data correctly.

It feels like weewx is storing rain in a way I don't understand.
Or, the wee_import suffers from the same missing issue as normal
interceptor.

Edit 2: It seems almost surely that the import has the same
erroneous result as normal operation.
If you want to see what I mean:
https://weewx.simple-earth.org/reports/?yr=2023 <- 401mm for the
year vs over 800 on ecowitt (which is also what WU and my console
and my plastic rainguage agrees on).
I set import to cumulative, so midnight resets were valid.

WeeWX is storing rain somewhere and forgetting about it when it
creates graphs and reports? :D
Sorry, I am as desperate to solve this as I am confused. Two full
days on this now, feeling the pain.

On Wednesday, 01 November 2023 at 10:34:11 UTC+2 Rainer Lang wrote:

And, to improve your knowledge of your weather station, I
recommend reading the WiKi at

https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen
if you understand German (the Froggit brand may point to that).
If not, try https://www.wxforum.net/index.php?topic=40730.0 in
English - not as extensive but the best on the web in English
language
by the same author

On 01.11.2023 09:27, Rainer Lang wrote:


I think you have to understand better how weewx works:
even if you set a archive interval of 300 seconds (5
minutes), each data packet sent by your console every 16
seconds (shorter doesn't make sense for you anyway as the
outdoor sensor array only transmits every 16 seconds) is
processed by weewx and added to its Loop data according to
the accumulator setup. The "loop" is a table in which all
data which occur during an archive interval are collected
[summarized, averaged etc.] and the last version is then
archived at the end of the archiving interval. So nothing
gets lost and you don't need to archive every 16 seconds ...

You can find a proper interceptor.py and extensions.py at
https://pc-wetterstation.de/weewx/usr/share/weewx/user/interceptor.zip
and
https://pc-wetterstation.de/weewx/usr/share/weewx/user/extensions.zip


On 01.11.2023 09:17, Marlon wrote:

Hi Rainer
Thank you for the reply.
You are right, that is an absurd interval (Im not sure if
late nights or desperate times caused it).
My console reports (well, POST's) every 16s (the minimum
setting). I am going to increase my archive interval to 60s,
or perhaps 32s. Not sure if it should be divisible by my
console's abilities.

As for the driver, thanks. Didn't know Interceptor was so
outdated. Unfortunately, I am not sure what else my
froggit/fineOffset WH3000 can use. I couldn't get the
standard ones to work.

Appreciated.
Marlon


On Wednesday, 01 November 2023 at 10:11:48 UTC+2 Rainer Lang
wrote:

a) you should use an interceptor driver version which
cleanly handles all your sensors - and also those you
don't have
the original version on GitHub was never extended and is
a crippled version from a today's point of view as it
covers the basic sensors only and its exclusio

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-01 Thread 'Rainer Lang' via weewx-user

And, to improve your knowledge of your weather station, I recommend 
reading the WiKi at

https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen
if you understand German (the Froggit brand may point to that).
If not, try https://www.wxforum.net/index.php?topic=40730.0 in English - 
not as extensive but the best on the web in English language

by the same author

On 01.11.2023 09:27, Rainer Lang wrote:


I think you have to understand better how weewx works:
even if you set a archive interval of 300 seconds (5 minutes), each 
data packet sent by your console every 16 seconds (shorter doesn't 
make sense for you anyway as the outdoor sensor array only transmits 
every 16 seconds) is processed by weewx and added to its Loop data 
according to the accumulator setup. The "loop" is a table in which all 
data which occur during an archive interval are collected [summarized, 
averaged etc.] and the last version is then archived at the end of the 
archiving interval. So nothing gets lost and you don't need to archive 
every 16 seconds ...


You can find a proper interceptor.py and extensions.py at
https://pc-wetterstation.de/weewx/usr/share/weewx/user/interceptor.zip
and
https://pc-wetterstation.de/weewx/usr/share/weewx/user/extensions.zip


On 01.11.2023 09:17, Marlon wrote:

Hi Rainer
Thank you for the reply.
You are right, that is an absurd interval (Im not sure if late nights 
or desperate times caused it).
My console reports (well, POST's) every 16s (the minimum setting). I 
am going to increase my archive interval to 60s, or perhaps 32s. Not 
sure if it should be divisible by my console's abilities.


As for the driver, thanks. Didn't know Interceptor was so outdated. 
Unfortunately, I am not sure what else my froggit/fineOffset WH3000 
can use. I couldn't get the standard ones to work.


Appreciated.
Marlon


On Wednesday, 01 November 2023 at 10:11:48 UTC+2 Rainer Lang wrote:

a) you should use an interceptor driver version which cleanly
handles all your sensors - and also those you don't have
the original version on GitHub was never extended and is a
crippled version from a today's point of view as it covers the
basic sensors only and its exclusion field-map is incomplete -
doesn't match the current customized server protocol sent by a
modern Ecowitt console with more than the basic sensors connected
- extended, complete and working versions of interceptor.py and
extensions.py (for units) exist though
if you use the device_type ecowitt-client as you already found
out yourself, the assignment of the rain data should work properly
But that's "beauty talk"

b) what hits my eye is your archiving interval of 15 seconds ...

Nov  1 09:04:25 goatbox weewx[281767] INFO weewx.engine: Using
archive interval of 15 seconds (software record generation)

I have no idea what added value you try to get from such a short
interval and it may overload the system and be - at least
partially - responsible for your issue.

On 01.11.2023 08:36, Marlon wrote:

Sorry, I see a part of the log that was missing (i had it on
wu-client, testing... correct setting is ecowitt-client in
interceptor).
Either way, the raw POST contains this:

Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor:
POST:

b'PASSKEY==EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'

Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor:
raw data:

b'PASSKEY=660D031A3A77C1332DFA76B2C975573C=EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'

A few types of rain params there.

On Wednesday, 01 November 2023 at 09:08:32 UTC+2 Marlon wrote:

Hey there Gary
Your response, and the time you spent, is most appreciated.
Thank you.

To simplify things, let's ignore the "import" problem, that
may (probably is) just user error and config. PS: for what
it's worth, my rain data in the csv's are cumulative. So
every hour, adds up the total until midnight where it
becomes 0.0 again.

You're triggering some ideas here, regarding timing. I will
share my startup log head now.
When I know the rain data matches the other sites, ecowitt,
WU, Weathercloud... I will disable posting to those services
and just use weewx. Even simpler.

Under-readding seems to be at a daily level (or event, which
is what I can humanly notice when I look at the console, WU,
ecowitt and weewx). An event would end, and everything would
say, eg: 32.5mm, but weewx would be at 26mm. Even during
rain, it would be behind

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-01 Thread 'Rainer Lang' via weewx-user


I think you have to understand better how weewx works:
even if you set a archive interval of 300 seconds (5 minutes), each data 
packet sent by your console every 16 seconds (shorter doesn't make sense 
for you anyway as the outdoor sensor array only transmits every 16 
seconds) is processed by weewx and added to its Loop data according to 
the accumulator setup. The "loop" is a table in which all data which 
occur during an archive interval are collected [summarized, averaged 
etc.] and the last version is then archived at the end of the archiving 
interval. So nothing gets lost and you don't need to archive every 16 
seconds ...


You can find a proper interceptor.py and extensions.py at
https://pc-wetterstation.de/weewx/usr/share/weewx/user/interceptor.zip
and
https://pc-wetterstation.de/weewx/usr/share/weewx/user/extensions.zip


On 01.11.2023 09:17, Marlon wrote:

Hi Rainer
Thank you for the reply.
You are right, that is an absurd interval (Im not sure if late nights 
or desperate times caused it).
My console reports (well, POST's) every 16s (the minimum setting). I 
am going to increase my archive interval to 60s, or perhaps 32s. Not 
sure if it should be divisible by my console's abilities.


As for the driver, thanks. Didn't know Interceptor was so outdated. 
Unfortunately, I am not sure what else my froggit/fineOffset WH3000 
can use. I couldn't get the standard ones to work.


Appreciated.
Marlon


On Wednesday, 01 November 2023 at 10:11:48 UTC+2 Rainer Lang wrote:

a) you should use an interceptor driver version which cleanly
handles all your sensors - and also those you don't have
the original version on GitHub was never extended and is a
crippled version from a today's point of view as it covers the
basic sensors only and its exclusion field-map is incomplete -
doesn't match the current customized server protocol sent by a
modern Ecowitt console with more than the basic sensors connected
- extended, complete and working versions of interceptor.py and
extensions.py (for units) exist though
if you use the device_type ecowitt-client as you already found out
yourself, the assignment of the rain data should work properly
But that's "beauty talk"

b) what hits my eye is your archiving interval of 15 seconds ...

Nov  1 09:04:25 goatbox weewx[281767] INFO weewx.engine: Using
archive interval of 15 seconds (software record generation)

I have no idea what added value you try to get from such a short
interval and it may overload the system and be - at least
partially - responsible for your issue.

On 01.11.2023 08:36, Marlon wrote:

Sorry, I see a part of the log that was missing (i had it on
wu-client, testing... correct setting is ecowitt-client in
interceptor).
Either way, the raw POST contains this:

Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor:
POST:

b'PASSKEY==EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'

Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor: raw
data:

b'PASSKEY=660D031A3A77C1332DFA76B2C975573C=EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'

A few types of rain params there.

On Wednesday, 01 November 2023 at 09:08:32 UTC+2 Marlon wrote:

Hey there Gary
Your response, and the time you spent, is most appreciated.
Thank you.

To simplify things, let's ignore the "import" problem, that
may (probably is) just user error and config. PS: for what
it's worth, my rain data in the csv's are cumulative. So
every hour, adds up the total until midnight where it becomes
0.0 again.

You're triggering some ideas here, regarding timing. I will
share my startup log head now.
When I know the rain data matches the other sites, ecowitt,
WU, Weathercloud... I will disable posting to those services
and just use weewx. Even simpler.

Under-readding seems to be at a daily level (or event, which
is what I can humanly notice when I look at the console, WU,
ecowitt and weewx). An event would end, and everything would
say, eg: 32.5mm, but weewx would be at 26mm. Even during
rain, it would be behind the console and other services.

I'm REALLY pondering the timing thing, and I think you're on
to something about missing intercepts/timing.

Unfortunately, I am very much in the dark about how these
timings work. I use WSView to configure my FineOffset WH
clone, and the minimum rate is every 16s (which is my setting).
With what interval and "loop packets" mean, I can't figure it
o

Re: [weewx-user] Re: Rain Underreading: Discrepancies even when importing from csv

2023-11-01 Thread 'Rainer Lang' via weewx-user

a) you should use an interceptor driver version which cleanly handles 
all your sensors - and also those you don't have
the original version on GitHub was never extended and is a crippled 
version from a today's point of view as it covers the basic sensors only 
and its exclusion field-map is incomplete - doesn't match the current 
customized server protocol sent by a modern Ecowitt console with more 
than the basic sensors connected - extended, complete and working 
versions of interceptor.py and extensions.py (for units) exist though
if you use the device_type ecowitt-client as you already found out 
yourself, the assignment of the rain data should work properly

But that's "beauty talk"

b) what hits my eye is your archiving interval of 15 seconds ...
Nov  1 09:04:25 goatbox weewx[281767] INFO weewx.engine: Using archive 
interval of 15 seconds (software record generation)


I have no idea what added value you try to get from such a short 
interval and it may overload the system and be - at least partially - 
responsible for your issue.


On 01.11.2023 08:36, Marlon wrote:
Sorry, I see a part of the log that was missing (i had it on 
wu-client, testing... correct setting is ecowitt-client in interceptor).

Either way, the raw POST contains this:

Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor: POST: 
b'PASSKEY==EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'


Nov  1 09:32:58 goatbox weewx[281767] DEBUG user.interceptor: raw 
data: 
b'PASSKEY=660D031A3A77C1332DFA76B2C975573C=EasyWeatherV1.6.6=2023-11-01+07:32:56=71.1=54=29.540=29.602=69.8=57=78=1.8=2.2=11.4=0.000=0.000=0.000=0.000=0.008=0.000=32.445=32.445=839.34=8=0=868M=WS2900_V2.01.08'


A few types of rain params there.

On Wednesday, 01 November 2023 at 09:08:32 UTC+2 Marlon wrote:

Hey there Gary
Your response, and the time you spent, is most appreciated. Thank you.

To simplify things, let's ignore the "import" problem, that may
(probably is) just user error and config. PS: for what it's worth,
my rain data in the csv's are cumulative. So every hour, adds up
the total until midnight where it becomes 0.0 again.

You're triggering some ideas here, regarding timing. I will share
my startup log head now.
When I know the rain data matches the other sites, ecowitt, WU,
Weathercloud... I will disable posting to those services and just
use weewx. Even simpler.

Under-readding seems to be at a daily level (or event, which is
what I can humanly notice when I look at the console, WU, ecowitt
and weewx). An event would end, and everything would say, eg:
32.5mm, but weewx would be at 26mm. Even during rain, it would be
behind the console and other services.

I'm REALLY pondering the timing thing, and I think you're on to
something about missing intercepts/timing.

Unfortunately, I am very much in the dark about how these timings
work. I use WSView to configure my FineOffset WH clone, and the
minimum rate is every 16s (which is my setting).
With what interval and "loop packets" mean, I can't figure it out.

Again, thanks for the reply.
Startup log follows, ugly spam paste warning:

root@goatbox:/etc/weewx# service weewx start && tail -f
/var/log/syslog | grep weewx
Nov  1 09:04:25 goatbox weewx[281764] INFO __main__: Locale is
'C.UTF-8'
Nov  1 09:04:25 goatbox weewx[281764] INFO __main__: Using
configuration file /etc/weewx/weewx.conf
Nov  1 09:04:25 goatbox weewx[281764] INFO __main__: Debug is 1
Nov  1 09:04:25 goatbox weewx[281764] INFO __main__: PID file is
/var/run/weewx.pid
Nov  1 09:04:25 goatbox weewx[281767] DEBUG __main__: Initializing
engine
Nov  1 09:04:25 goatbox weewx[281767] INFO weewx.engine: Loading
station type Interceptor (user.interceptor)
Nov  1 09:04:25 goatbox weewx[281753]:    ...done.
Nov  1 09:04:25 goatbox systemd[1]: Started LSB: weewx weather system.
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor:
driver version is 0.60
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor:
device type: wu-client
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor:
hardware name: weatherstation via interceptor
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor: mode
is listen
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor:
listen on :8066
Nov  1 09:04:25 goatbox weewx[281767] INFO user.interceptor:
sensor map: {'pressure': 'pressure', 'barometer': 'barometer',
'outHumidity': 'humidity_out', 'inHumidity': 'humidity_in',
'outTemp': 'temperature_out', 'inTemp': 'temperature_in',
'windSpeed': 'wind_speed', 'windGust': 'wind_gust', 'windDir':
'wind_dir', 'windGustDir': 'wind_gust_dir', 'radiation':
'solar_radiation', 'dewpoint': 'dewpoint',

Re: [weewx-user] Re: Restore weewx Database from Ecowitt.net

2023-11-01 Thread 'Rainer Lang' via weewx-user

the download from the Ecowitt cloud is not fully based on their public 
http-API - it rather offers a "canon ball" solution as the author says


for details about the API see https://doc.ecowitt.net/
if you want to develop your own thing or create a more specific solution 
using the accounts APP and API keys (to be created in the account)


the link provided by @Marlon seems to be a working solution, however it 
has some caveats you might want to consider

(like other things you might do)

- it downloads data from all devices connected to your user account (if 
you have only once console, then there's no issue here)
=> if you have more devices, you will get several CSV files with the 
device-ID (=MAC address I guess, that's what the device ID is on 
ecowitt.net) as file name


- you have to consider the resolution and retention times at ecowitt.net
=> you may have to run the script let's say every two months to have a 5 
minute resolution of the data on ecowitt.net as CSV as potential backup

see https://www.wxforum.net/index.php?topic=40730.0 chapter 14

- the download will not be complete if you have extra sensors beyond the 
basic sensors - its "field map" would need to be extended, especially 
for a WS90 outdoor array and its "piezo data" if you have one and for 
the battery values (depends on what you store in your weewx database



A more specific method would be using the APP and API keys together with 
the device ID and providing a starting and ending time stamp (down to a 
5 minute slice) - e.g. a (still to be created) weewx extension with an 
automatic refill from ecowitt.net at restart when needed (i.e. when 
there was a - wanted or unwanted- interruption of the data logging 
bigger than the weewx archiving intervall) as already implemented ever 
since the API was published in the CumulusMX software.


On 01.11.2023 07:29, Tim Tuck wrote:

HI Vince,

I might do that.

But I've posted here since this was script originally announced here 
so the developer should see this anyway.


Also there are many weewx user who have Ecowitt kit and repopulating 
the db from the Ecowitt server is something that others may have done, 
hence my question :)


regards

Tim

On 1/11/23 16:04, vince wrote:

Perhaps you might open a github issue at the repo you mentioned..,,






--
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/2360f04c-95ec-40ef-9f37-0158d354c5cb%40gmail.com.

Re: [weewx-user] Re: How to revive 'frozen' WeeWX?

2023-10-18 Thread 'Rainer Lang' via weewx-user


you can install (unless already installed) the ncdu tool:
sudo apt-get install ncdu
and you'll have to run it in the root directory in a console window on 
your RPi
it will give you a nice and complete overview which directories use 
which storage capacity down to the files


On 18.10.2023 13:57, Dale Chatham wrote:

Suggestion to determine where al the space is being used.

Go to the mount point of the filesystem n question, in this case, /
Run the command du -s *  | sort -n
The directories/files with the largest usage will show up at the 
bottom of the list.

If a directory, cd into that directory and run du -s * | sort again.
Eventually you will find it.

Note that a file open for writing but not yet closed may not appear.  
A reboot may either make it visible or get rid of it.


A good start if it is in /var/log is to blow away all the gzipped log 
files.  Those have been archived and compressed by logwatch and should 
not affect anything.  Per my above comment, deleting an open file will 
merely delete the directory entry, not the file.  If you want to 
remove the space used by those, try "> filename".


On Wednesday, October 18, 2023 at 3:05:08 AM UTC-5 Ton vanN wrote:

After removal of .1-files and .gz-files for checking reran df, showing

Bestandssysteem 1K-blokken Gebruikt Beschikbaar Geb% Aangekoppeld op
/dev/root         30358348 28786676      287176 100% /

devtmpfs            439400        0      439400   0% /dev
tmpfs               472680        0      472680   0% /dev/shm
tmpfs               472680    47796      424884  11% /run

tmpfs                 5120        4        5116   1% /run/lock
tmpfs               472680        0      472680   0% /sys/fs/cgroup
/dev/mmcblk0p1      258095    49395      208700  20% /boot
tmpfs                94536        4       94532   1% /run/user/1000

/dev/root at 100% occupancy does not seem healthy, and breeding
new problems  ...

Op dinsdag 17 oktober 2023 om 22:15:54 UTC+2 schreef vince:

Just delete the big logs from /var/log and reboot - that's all
you need to do.


With you providing no data on which files in /var/log are the
big ones, no we can't help you much.

On Tuesday, October 17, 2023 at 1:13:19 PM UTC-7 Ton vanN wrote:

Was on wrong leg, assuming KBs .
Unpleasant surprise, which seems to lead to conclusion
that this install cannot be saved, but new start required.
What is best practical approach to make new, small
configuration while 'borrowing' from the old configuration
the sdb-file and various conf-files?
Somewhere a description for that kind of clean-up/restart?

Obviously keen to avoid the 'error' that lead to this
'saturated' install:
any hint?

Op dinsdag 17 oktober 2023 om 13:06:53 UTC+2 schreef Tom
Keffer:

The "-m" option to du means that sizes are in
/megabytes/. Your /var/log directory has 26
/gigabytes/ in it.

On Tue, Oct 17, 2023 at 2:12 AM Ton vanN
 wrote:

Vince,
The results of the suggested checks.

*raspberrypi9*:~ $ sudo du -sm /var/log
25977   /var/log
*raspberrypi9:~ $ *sudo du -sm /tmp
1       /tmp
*raspberrypi9:~ $* sudo du -sm /home/pi
53      /home/pi
*raspberrypi9:~ $* sudo du -sm /var/tmp
1       /var/tmp

IMHO contents of checked files are minimal 
Wondering why /dev/root full, with this Raspberry
only running WeeWX plus 2 auxiliary Python-scripts
(sized 2KB and 1KB), serving periodic upload of
weewx.sdb to a remote, backup server

Guessing/speculation:
might expansion of the file system (via
raspi-config) have had some effects?
Op maandag 16 oktober 2023 om 20:58:56 UTC+2
schreef vince:

Your / partition is full.     You have 29G
Size and 29G Used and 0 Available.

*raspberrypi9:~ $* df -h
Bestandssysteem Grootte Gebruikt Besch Geb%
Aangekoppeld op
/dev/root           29G      29G 0 100% /
devtmpfs           430M        0  430M   0% /dev
tmpfs              462M        0  462M   0%
/dev/shm
tmpfs              462M      47M  415M  11% /run
tmpfs              5,0M     4,0K  5,0M   1%
/run/lock

Re: [weewx-user] Re: Cannot get weewx + gw1000 working

2023-10-17 Thread 'Rainer Lang' via weewx-user

      File 
"/usr/share/weewx/user/gw1000.py", line 2311, in __init__
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           super(GatewayDriver, 
self).__init__(**stn_dict)
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 1014, in __init__
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           self.collector = 
GatewayCollector(ip_address=self.ip_address,
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:      

Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 2608, in __init__
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           self.device = 
GatewayDevice(ip_address=ip_address, port=port,
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:      
 ^^^
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 6024, in __init__
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           self.api = 
GatewayApi(ip_address=ip_address,
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:      ^
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 4769, in __init__
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           self.model = 
self.get_model_from_firmware(self.get_firmware_version())
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:                     ^^^
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 5217, in get_firmware_version
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           response = 
self.send_cmd_with_retries('CMD_READ_FIRMWARE_VERSION')
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:      
^^^
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:         File 
"/usr/share/weewx/user/gw1000.py", line 5454, in send_cmd_with_retries
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:           raise GWIOError(_msg)
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL weewx.engine:       user.gw1000.GWIOError: Failed to 
obtain response to command 'CMD_READ_FIRMWARE_VERSION' after 3 attempts
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL __main__: Unable to load driver: Failed to obtain response to 
command 'CMD_READ_FIRMWARE_VERSION' after 3 attempts
Oct 17 15:25:24 fedora-workstation python3[53515]: weewx[53515] 
CRITICAL __main__:       Waiting 60 seconds then retrying...
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
__main__: retrying...
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] DEBUG 
__main__: Initializing engine
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
weewx.engine: Loading station type GW1000 (user.gw1000)
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000: GatewayDriver: version is 0.6.0b2
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000:      device address is 192.168.50.41:45000
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000:      poll interval is 10 seconds
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000:      max tries is 3, retry wait time is 10 seconds
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000:      broadcast address is 255.255.255.255:46000, 
broadcast timeout is 5 seconds
Oct 17 15:26:24 fedora-workstation python3[53515]: weewx[53515] INFO 
user.gw1000:      socket timeout is 2 seconds


e.  Since both the weewx server and the weather station are on the 
same network, I'm not sure a firewall wold come into play.  However, I 
disabled the firewall, no change, nor do I see anything that wold 
block the local network.
f.  Not sure what "bound to" means in this context, but according to 
the router, it understands bot th eIP and MAC to belong to the weewx 
access point.




FWIW, running weewx

[weewx-user] Re: Cannot get weewx + gw1000 working

2023-10-17 Thread 'Rainer Lang' via weewx-user

I meant of course
set *debug = 3*

 Forwarded Message 
Subject:Re: [weewx-user] Re: Cannot get weewx + gw1000 working
Date:   Tue, 17 Oct 2023 15:32:48 +0200
From:   Rainer Lang 
To: weewx-user@googlegroups.com

it's difficult to follow what you are/were doing - it would be helpful 
if you
a) provided us with a copy of your weewx.conf (you can  your 
passwords if there are any)

b) set your station to GW1000
c) set debug = 0
d) provided the complete syslog from weewx startup until either the 1st 
report cycle is completed (as a rule after 5 minutes)

or weewx exits because of an unrecoverable error - snippets are not helpful

e) you should check if the IP address of your GW1000 is bound to its MAC 
address
f) you should check if some option in your router to allow intranetwork 
communication is set/untagged etc.

On 17.10.2023 15:20, Dale Chatham wrote:

Yet another data point:

python -m user.gw1000 --test-service --debug=5 
--ip-address=192.168.50.41 --port=45000

Using configuration file /etc/weewx/weewx.conf
debug level is '5'

IP address obtained from command line options
Port number obtained from command line options
Battery state filtering is 'False' (using the default)
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/share/weewx/user/gw1000.py", line 8229, in 
    main()
  File "/usr/share/weewx/user/gw1000.py", line 8225, in main
    direct_gw.process_options()
  File "/usr/share/weewx/user/gw1000.py", line 6745, in process_options
    self.test_service()
  File "/usr/share/weewx/user/gw1000.py", line 8047, in test_service
    engine = weewx.engine.StdEngine(config)
             ^^
  File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
    self.loadServices(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
    obj = weeutil.weeutil.get_object(svc)(self, config_dict)
          ^^
  File "/usr/share/weewx/user/gw1000.py", line 1389, in __init__
    loginf('     field map is %s' % natural_sort_dict(self.field_map))
^^
AttributeError: 'GatewayService' object has no attribute 'field_map'

On Tuesday, October 17, 2023 at 8:08:00 AM UTC-5 Dale Chatham wrote:

Another data point:

nmap -sV -p 1-65535 192.168.50.41
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-17 06:51 CDT
Nmap scan report for ecowitt-weather (192.168.50.41)
Host is up (0.0069s latency).
Not shown: 65533 closed tcp ports (reset)
PORT      STATE SERVICE     VERSION
80/tcp    open  nagios-nsca Nagios NSCA
45000/tcp open  asmp?
MAC Address: BC:FF:4D:1C:C0:69 (Espressif)

It appears the port is open on the access point, but it's not
answering.  Any ideas?

On Tuesday, October 17, 2023 at 6:32:48 AM UTC-5 Dale Chatham wrote:

Is it possible to get an help here?

On Thursday, October 12, 2023 at 9:30:22 PM UTC-5 Dale Chatham
wrote:

I blew it away and started over.

Installed weewx according to:
https://weewx.com/docs/redhat.htm Simulator worked fine.

Inst alled Ecowitt Gateway servier according to:
https://github.com/gjr80/weewx-gw1000/blob/master/readme.txt

Ran PYTHONPATH=/usr/share/weewx python -m user.gw1000
--test-driver from the above file.

I get this error:
Using configuration file /etc/weewx/weewx.conf

Unable to connect to device: Failed to obtain response to
command 'CMD_READ_FIRMWARE_VERSION' after 3 attempts

    Things to check include that the correct device IP
address is being used,
    the device is powered on and the device is not
otherwise disconnected from
    the local network.

I used telnet to connect to the IP and port listed in
weewx.conf:
    driver = user.gw1000
    ip_address = 192.168.50.41
    port = 45000

I get a connection, but canot get a response to anyting I
type (I have no idea if/what should be enteed to get a
response.

On Wednesday, October 11, 2023 at 6:13:20 AM UTC-5 gjr80
wrote:

I'm not sure what you are trying to do. The link you
provided uses a custom WeeWX data service to parse a
text file from the Ecowitt device, but the log extract
you provided contains errors relating to the Ecowitt
gateway driver <https://github.com/gjr80/weewx-gw1000>
which uses the Ecowitt gateway device API to read data
from the Ecowitt gateway device. You need to choose

Re: [weewx-user] Re: Cannot get weewx + gw1000 working

2023-10-17 Thread 'Rainer Lang' via weewx-user

it's difficult to follow what you are/were doing - it would be helpful 
if you
a) provided us with a copy of your weewx.conf (you can  your 
passwords if there are any)

b) set your station to GW1000
c) set debug = 0
d) provided the complete syslog from weewx startup until either the 1st 
report cycle is completed (as a rule after 5 minutes)

or weewx exits because of an unrecoverable error - snippets are not helpful

e) you should check if the IP address of your GW1000 is bound to its MAC 
address
f) you should check if some option in your router to allow intranetwork 
communication is set/untagged etc.


On 17.10.2023 15:20, Dale Chatham wrote:

Yet another data point:

python -m user.gw1000 --test-service --debug=5 
--ip-address=192.168.50.41 --port=45000

Using configuration file /etc/weewx/weewx.conf
debug level is '5'

IP address obtained from command line options
Port number obtained from command line options
Battery state filtering is 'False' (using the default)
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/share/weewx/user/gw1000.py", line 8229, in 
    main()
  File "/usr/share/weewx/user/gw1000.py", line 8225, in main
    direct_gw.process_options()
  File "/usr/share/weewx/user/gw1000.py", line 6745, in process_options
    self.test_service()
  File "/usr/share/weewx/user/gw1000.py", line 8047, in test_service
    engine = weewx.engine.StdEngine(config)
             ^^
  File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
    self.loadServices(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
    obj = weeutil.weeutil.get_object(svc)(self, config_dict)
          ^^
  File "/usr/share/weewx/user/gw1000.py", line 1389, in __init__
    loginf('     field map is %s' % natural_sort_dict(self.field_map))
^^
AttributeError: 'GatewayService' object has no attribute 'field_map'


On Tuesday, October 17, 2023 at 8:08:00 AM UTC-5 Dale Chatham wrote:

Another data point:

nmap -sV -p 1-65535 192.168.50.41
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-17 06:51 CDT
Nmap scan report for ecowitt-weather (192.168.50.41)
Host is up (0.0069s latency).
Not shown: 65533 closed tcp ports (reset)
PORT      STATE SERVICE     VERSION
80/tcp    open  nagios-nsca Nagios NSCA
45000/tcp open  asmp?
MAC Address: BC:FF:4D:1C:C0:69 (Espressif)

It appears the port is open on the access point, but it's not
answering.  Any ideas?


On Tuesday, October 17, 2023 at 6:32:48 AM UTC-5 Dale Chatham wrote:

Is it possible to get an help here?

On Thursday, October 12, 2023 at 9:30:22 PM UTC-5 Dale Chatham
wrote:

I blew it away and started over.

Installed weewx according to:
https://weewx.com/docs/redhat.htm Simulator worked fine.

Inst alled Ecowitt Gateway servier according to:
https://github.com/gjr80/weewx-gw1000/blob/master/readme.txt

Ran PYTHONPATH=/usr/share/weewx python -m user.gw1000
--test-driver from the above file.

I get this error:
Using configuration file /etc/weewx/weewx.conf

Unable to connect to device: Failed to obtain response to
command 'CMD_READ_FIRMWARE_VERSION' after 3 attempts

    Things to check include that the correct device IP
address is being used,
    the device is powered on and the device is not
otherwise disconnected from
    the local network.

I used telnet to connect to the IP and port listed in
weewx.conf:
    driver = user.gw1000
    ip_address = 192.168.50.41
    port = 45000

I get a connection, but canot get a response to anyting I
type (I have no idea if/what should be enteed to get a
response.



On Wednesday, October 11, 2023 at 6:13:20 AM UTC-5 gjr80
wrote:

I'm not sure what you are trying to do. The link you
provided uses a custom WeeWX data service to parse a
text file from the Ecowitt device, but the log extract
you provided contains errors relating to the Ecowitt
gateway driver 
which uses the Ecowitt gateway device API to read data
from the Ecowitt gateway device. You need to choose
one method or the other, not both. If your intent is
to utilise the linked page in your original post then
you should uninstall the Ecowitt gateway driver.

Gary
On Wednesday, 11 October 2023 at 08:41:26 UTC+10
dale.c...@gmail.com wrote:

Re: [weewx-user] Heat index and wind chill WS90 with GW1000 driver

2023-10-15 Thread 'Rainer Lang' via weewx-user

correct - the API description has 0x03, 0x04 and 0x05 for dew point, 
wind chill and heat index, but the GW1x00/GW2000/WN19x0 
consoles/gateways do not calculate them for the API response - 
therefore, until now, 0x03 thru 0x05 won't be found in an API response. 
The live data view of the WS View (Plus) app only shows FeelsLike and 
Dew point because WS View Plus calculates them. Same with this data in 
the Ecowitt cloud (which is read by the Ecowitt app) - they are 
calculated there and not sent by the console.


On 15.10.2023 11:21, gjr80 wrote:
Just to clarify, the Ecowitt gateway device Data Exchange TCP protocol 
(aka the Ecowitt gateway device API) includes provision for wind chill 
and heat index, but I have not yet seen a gateway device that actually 
provides such data. The Ecowitt gateway device driver passes these 
fields through to the corresponding WeeWX fields, but of course this 
only occurs if the gateway device actually provides the data. The 
easiest way to confirm what is coming from the hardware is to run the 
driver directly using the --live-data command line option, eg for a 
setup.py install:


$ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data

or for a package install

$ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --live-data

this can be done while WeeWX is running. (note you may need to replace 
/python/ with /python2/ or /python3/ depending on your system).


If you see heatindex or windchill then it was provided by your 
hardware, if they do not exist then your hardware did not provide heat 
index and wind chill data. If the latter then almost certainly the 
heatindex and windchill field values you saw were calculated by WeeWX. 
Note the default StdWxCalculate settings for the heatindex and 
windchill fields is prefer_hardware, which means WeeWX will default to 
heat index and wind chill from the station if available, otherwise 
WeeWX will attempt to calculate them. Note the prefer_hardware setting 
is different to the hardware setting.


Bottom line is if WeeWX was already calculating heatindex and 
windchill then I suspect your issue is the veracity of your 
temperature, humidity and/or wind speed data (ie the source data for 
calculating heat index and wind chill).


Gary
On Sunday, 15 October 2023 at 01:05:33 UTC+10 zasp...@gmail.com wrote:

hi
Ok thanks for the advice and information i will put it into
software calculation


On Saturday, 14 October 2023 at 13:27:22 UTC+1 Rainer Lang wrote:

nothing is "amiss" in the "WS90 software", whatever you mean
by this.
I think you have a wrong understanding of the hardware you are
using and its (assumed) capabilities.

1. Tom's hint will solve your issue in weewx, as the
observations you are asking for are not primary observations
but derived observations - they are calculated from primary
observations - either by a console of by the data logging
software (here weewx).

2. The WS90 sensor array portion which reads the values from
which wind chill and heat index etc. can be derived is the
T/RH sensor. It reads the outdoor temperature and air
humidity. More the sensor doesn't do. The console, be it a
GW1000/GW1100/GW2000/WN19x0/WH2650, processes the observations
from the sensor array (wind, wind direction, rain rate, solar
and outdoor T/RH) and creates certain derived values like dew
point.

What the sensor reads can be found in the sensor specification
- the same is true for the console: its output is defined by
the API definition. If you want to know details, read
https://www.wxforum.net/index.php?topic=40730.0 chapter 13:
the Ecowitt Gateway API (application programming interface)
aka GW1000 API

There you will see that heat index, humidex, feels like, wind
chill etc. are not part of that output.
Weewx has the possibility to calculate these values from the
basic observations => [[calculations]] where you can tell
weewx not to expect these values from the console/driver (=
hardware) but to do the calculations itself ( = software)


On 14.10.2023 14:03, Tom Keffer wrote:

See the documentation, section [[Calculations]]
<http://www.weewx.com/docs/usersguide.htm#[[Calculations]]>.

So you would end up with something like:

[StdWXCalculate]
  ...
  [[Calculations]]
    ...
    windchill=software
    heatindex=software


On Sat, Oct 14, 2023 at 12:56 AM zasp...@gmail.com
 wrote:

I have noticed that my heat index value is constantly
lower than the windchill value.

This value is set to hardware generation so assume
something is amiss inside the WS90 software.

What’s the best way t

Re: [weewx-user] Heat index and wind chill WS90 with GW1000 driver

2023-10-14 Thread 'Rainer Lang' via weewx-user

nothing is "amiss" in the "WS90 software", whatever you mean by this.
I think you have a wrong understanding of the hardware you are using and
its (assumed) capabilities.

1. Tom's hint will solve your issue in weewx, as the observations you
are asking for are not primary observations but derived observations -
they are calculated from primary observations - either by a console of
by the data logging software (here weewx).

2. The WS90 sensor array portion which reads the values from which wind
chill and heat index etc. can be derived is the T/RH sensor. It reads
the outdoor temperature and air humidity. More the sensor doesn't do.
The console, be it a GW1000/GW1100/GW2000/WN19x0/WH2650, processes the
observations from the sensor array (wind, wind direction, rain rate,
solar and outdoor T/RH) and creates certain derived values like dew point.

What the sensor reads can be found in the sensor specification - the
same is true for the console: its output is defined by the API
definition. If you want to know details, read
https://www.wxforum.net/index.php?topic=40730.0 chapter 13:

the Ecowitt Gateway API (application programming interface) aka GW1000 API

There you will see that heat index, humidex, feels like, wind chill etc.
are not part of that output.
Weewx has the possibility to calculate these values from the basic
observations => [[calculations]] where you can tell weewx not to expect
these values from the console/driver (= hardware) but to do the
calculations itself ( = software)

On 14.10.2023 14:03, Tom Keffer wrote:
See the documentation, section [[Calculations]]
.

So you would end up with something like:

[StdWXCalculate]
...
[[Calculations]]
...
windchill=software
heatindex=software

On Sat, Oct 14, 2023 at 12:56 AM zasp...@gmail.com
wrote:

I have noticed that my heat index value is constantly lower than
the windchill value.

This value is set to hardware generation so assume something is
amiss inside the WS90 software.

What’s the best way to rectify it swap to software generation or
swap the bindings between windchill and heat index?

Thanks for any advice

--
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/a2130e32-3481-4ec8-889d-07670dd6144en%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/CAPq0zECgx7s7u0pQCfQrVv6hr4nA65UYupQB4Fy6YnzQ%2Bbekcw%40mail.gmail.com
.

[weewx-user] Correct data in weewx.sdb

2023-09-19 Thread 'Rainer Lang' via weewx-user

sent my reply only privately by mistake - here for the group to benefit 
to the group too


 Forwarded Message 
Subject:Re: [weewx-user] Correct data in weewx.sdb
Date:   Tue, 19 Sep 2023 13:58:30 +0200
From:   Rainer Lang 
To: bgra...@umw.edu 



the easiest way imo is to use sqlitebrowser.

*sudo apt-get install sqlitebrowser*
then
*sudo sqlitebrowser /var/lib/weewx/weewx.sdb *
or wherever your weewx.sdb is located
(when you start sqlitebrowser without indicating the database name and 
load the database from within sqlitebrowser, it will be in read-only mode)

go to Browse Data, go to the end of file (bottom left >| )
locate your time stamp (EPOCH notation, first colum), go to the rain 
colum (slider)
change the value in the respective field (you will have to move the 
cursor off that filed into another one, otherwise the change will not be 
recognized)
go to "File" -> "Write changes..." - make sure you don't write the 
changes at the same time when weewx archives data (usually every full 5 
minutes) - otherwise the database will get locked foer weewx

i.e. do it between minute archive +1 and archive +4 minutes 
then rebuild the daily summaries with wee_database

On 18.09.2023 21:37, bgra...@umw.edu wrote:

Hello all,
A squirrel has placed a few items in my VP2 rain bucket and caused me 
to lose .44 inches of rain today.
What is the easiest way to modify the incorrect rain count and have 
all reports show this modified amount? The answer is probably easy but 
I can’t seem to figure this out. I need to add .44 inch to today’s 
total. I’m using weewx 4.10.1, ubuntu, and SQLight.

Thanks in advance.
Bob
--
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/c53078bb-fb5f-4052-96c7-8f5a3acb1364n%40googlegroups.com 
<https://groups.google.com/d/msgid/weewx-user/c53078bb-fb5f-4052-96c7-8f5a3acb1364n%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c37c882a-a5e1-bf60-29b0-ab78bb3292cc%40gmail.com.

Re: [weewx-user] Re: Confused about 'support' for stations w/o USB connection

2023-09-08 Thread 'Rainer Lang' via weewx-user

if you are going for a Ecowitt (clone) station, - look up
https://www.wxforum.net/index.php?topic=40730.0 to see what's available
from them these days and what they are able to do - then weewx will be
able to read their data which they all send via WLAN ("WiFi") to the
local network and/or the internet.

The Ecowitt Gateway API driver will do this for consoles with that
gateway API (GW1100, GW2000, WN19x0) or the Interceptor driver for the
consoles which don't have this API.
The consoles won't automatically post to weather services like
Wunderground, Ecowitt etc., only when you choose to do so.
In other words, weewx will either request the weather data via the
Ecowitt gateway API or the consoles will (after having been instructed
to do so) post their data to the server weewx is running on and weewx
picks them up. To get an idea about it (for Ecowitt (clone) consoles)
see the thread in the link above *chapter* *8* *data flow between
sensors, consoles, application software and internet weather services.*

It won't hurt to read that thread completely**

Ecowitt weather station today offer imo the best price/performance ratio
and widest range of sensor support on the market for private weather
stations in the 150-400 USD/EUR segment.

You are of course free to choose other manufacturers and more expensive
solutions if your wallet allows**

On 08.09.2023 20:44, James Deane wrote:
I should have mentioned that I have not yet acquired a new station --
that's what I'm looking at now, and I want to buy one that will do
what I was doing with my USB-connected 2080a.

On Friday, September 8, 2023 at 1:43:25 PM UTC-5 James Deane wrote:

Hi all, I hope this is not too basic for this group, but with my
2080a having failed I'm trying to figure out how to replicate the
functions I had built up for the old setup.

I use a Raspberry Pi with weewx to upload data to Wunderground,
CWOP, and PWSWeather. It seems most stations now have wifi
connectivity, so I assume they are automatically sending to
Wunderground -- but how does WeeWX get the data if there is no USB
connection to the weather station console? In other words, how do
I get it to CWOP and PWSWeather?

I see these wifi stations in the WeeWX compatibility list, so
surely there must be a method, but I"m just not clear on what it
might be.

Any help with my understanding would be greatly appreciated.

Jim

Re: [weewx-user] Barometer and pressure once again

2023-08-31 Thread 'Rainer Lang' via weewx-user

to calibrate your WS-1001 (Ambient version of the FineOffset/EcowittWH24
outdoor array and the WH1080 console) you could just follow the
instructions in https://www.wxforum.net/index.php?topic=40730.0 chapter 6
determine the offset and enter it accordingly (either an offest of
change the value, whatever the console wants --> manual).

METAR, airport etc. are secondary approaches for refinements which you
may or may not want to follow. There are lengthy and complex treatises
on that topic in the same forum, from simple to highly complex.

[by the way, if you have a European or international "version" of the
Ambient WS-1001 and call this a clone version, then that's very strange
wording as Ambient is the clone and not Fine Offset/Ecowitt = the
manufacturer]

but true, weewx should come to a proper result - and unless your station
also reports wrong absolute pressure (= local pressure) - or you display
the wrong variable/observation in your skin, then something is wrong
with weewx. Rather unlikely.

Did you read the barometer topic in the weewx online documentation ?

On 31.08.2023 10:29, Tomasz Lewicki wrote:

Rainer, Greg,

thank you both for thoughts and hints. Indeed, when I wrote "When
calculated by Weewx itself ("software" option enabled in weewx.conf),
my weather station shows 1001 hPa - still too low", I meant what Weewx
calculates and show on my webpage, not on console's display - display
is completely wrong in my opinion.

According to design of PWS, I own Ambient Weather WS-1001-WiFi clone.
I use HP-1000 driver. I don't know if it is designed wrong or not, but
I know that many people still use it.

Manual for my station say "To determine the relative pressure for your
location, locate an official reporting station near you (the internet
is the best source for real time barometer conditions, such as
Weather.com or Wunderground.com), and set your weather station to
match the official reporting station." I understand it, I should
calibrate PWS entering proper value from METAR for example.

But I still don't understand why Weewx, using "software" option for
calculating the sea-level (relative) pressure, shows too low value. As
I said, my station location AMSL in weewx.conf is "altitude = 550,
meter" (and for me it is neglible if it is 552 or 560; it is fraction
of 1 hPa). So the only way to show "real" value is to calibrate the
relative pressure (barometer in Weewx's terms) on the station's
display and set "prefer_hardware" in weewx.conf? I'm really confused.

Or maybe I have some units in weewx.conf messed up? I use metric
system so I entered meters when it was possible.

czwartek, 31 sierpnia 2023 o 02:39:14 UTC+2 Greg Troxel napisał(a):

from the wiki page I sent

For example, the FineOffset consoles can display either the station
pressure (called 'absolute' pressure) or the station pressure plus an
offset (called 'relative' pressure). T

So Fine Offset equipment just does pressure badly.

So get station pressure into weewx, do software from that, and
tape over
the "relative pressure" display on the console so nobody can see it!

Re: [weewx-user] Barometer and pressure once again

2023-08-30 Thread 'Rainer Lang' via weewx-user

yes - why not calibrate your console first
when you see that the offset between absolute and relative pressure for
your location used is wrong, just adjust it 

the the first basic step I'd say

even though, when your absolute (=local) pressure reading is correct,
and your have the weewx option in weewx.conf set to software, weewx
should calculate the proper relative value (taking into account the
average temperature of the past 12 hours afaik).

"When calculated by Weewx itself ("software" option enabled in
weewx.conf), my weather station shows 1001 hPa - still too low. " - I
guess what you want to say is not that your station shows too low a
value, but that weewx caluclates too low a value for your station (these
are two different things) - your station will continue to show what its
reads and what it is calibrated for. Weewx has no feedback to you station.

On 30.08.2023 20:21, Tomasz Lewicki wrote:
I'm trying to sort out barometer and pressure values. I own HP1001
clone. Internal T/H/P sensor was calibrated with my friends certified
barometer before. Currently it sensor shows absolute pressure value
936,7 hPa and it almost perfectly (+/- 1 hPa) aligns with very
accurate numerical forecast for my location. Same meteogram show also
relative pressure 1007 (+/- 1 hPa) for my location. METAR for nearby
(43 km) airport shows 1008 hPa.

Relative pressure displayed by my HP1001 is about 20 hPa higher than
absolute - obviously too low value because I'm located about 550 m AMSL.

When calculated by Weewx itself ("software" option enabled in
weewx.conf), my weather station shows 1001 hPa - still too low. Of
course I checked location setting and AMSL value and unit - in my
opinion they are properly set. Should I change something in weather
station settings? I can set only coordinates, not the AMSL height.

Re: [weewx-user] Re: GW1000 Ecowitt Gateway and WeeWx 5.0

2023-08-15 Thread 'Rainer Lang' via weewx-user


see inline below

On 15.08.2023 13:25, gert.a...@gmail.com wrote:

Hi Rainer
I did as you suggested and it seems to work now. gw1000.py was not 
there, so something went wrong during the installation.


A couple of questions:
1) I used sudo to install and WeeWX is running under root. Should I 
just use the user login(pi), to install WeeWx?
when you are acting as user pi, you need root rights - hence you use 
sudo 
installing weewx as any user, root or any other, hasn't been an issue so 
far (afaik)

2) Is the weewx.sdb compatible with Version 5?


I don't think the database type has changed (still either a sqlite3 
database or a MySQL database, and the weewx.sdb is/was a sqlite3 database)

- and you will probably still use the wview_extended database schema
what does weewx show when you use your "old" weewx.sdb in /var/lib/weewx ?
if you can see you historical data, all is fine 

3) Should I use pip to install or sudo apt install 
./python3-weewx_5, as I did


as far as I know the general weewx install instructions are valid - 
you can use apt and pip as package managers, depending on installation 
type

see weewx documentation



Thanks for helping

Rgds
Gert

On Tuesday, August 15, 2023 at 11:18:22 AM UTC+2 Rainer Lang wrote:

I think a simple solution could be to extract the file gw1000.py
from the gw1000-0.5.0b5.tar.gz archive and copy it to
/usr/share/weewx/user

On 15.08.2023 10:42, gert.a...@gmail.com wrote:

Hi Ian
Thanks for looking.
I used this command to install WeeWx:

sudo apt install ./python3-weewx_5.0.0a24-a_all.deb


and this command to install GW1000


sudo weectl extension install

https://github.com/gjr80/weewx-gw1000/releases/download/v0.5.0b5/gw1000-0.5.0b5.tar.gz


From syslog:

Aug 15 10:36:01 raspberrypi weewx[677] INFO weewx.engine: Loading
station type GW1000 (user.gw1000)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__: Caught
unrecoverable exception:
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
  No module named 'user.gw1000'
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
  Traceback (most recent call last):
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
    File "/usr/share/weewx/weewxd.py", line 149, in main
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
      engine = weewx.engine.StdEngine(config_dict)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
    File "/usr/share/weewx/weewx/engine.py", line 78, in __init__
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
      self.setupStation(config_dict)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
    File "/usr/share/weewx/weewx/engine.py", line 105, in
setupStation
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
      __import__(driver)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
  ModuleNotFoundError: No module named 'user.gw1000'
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:    
  Exiting.
Aug 15 10:36:01 raspberrypi systemd[1]: weewx.service: Main
process exited, code=exited, status=1/FAILURE
Aug 15 10:36:01 raspberrypi systemd[1]: weewx.service: Failed
with result 'exit-code'.


I have attached the weewx.conf file


Gert




On Tuesday, August 15, 2023 at 8:52:05 AM UTC+2 Ian Millard wrote:

How did you attempt the install? I am running version 5 with
a pip installation. I am also running the Gateway driver and
it installed seamlessly using weectl extension install [URL]

Sent from my iPad.


On 15 Aug 2023, at 05:57, gert.a...@gmail.com
 wrote:

Hi Vince
I followed the installation guide for the driver, but the
installation used the folder structure from WeeWx version 4.

Rgds
Gert

On Tuesday, August 15, 2023 at 1:44:12 AM UTC+2 vince wrote:

sure why wouldn't it be ?

On Monday, August 14, 2023 at 2:03:23 PM UTC-7
gert.a...@gmail.com wrote:

Hi
Is it possible to install the gateway with WeeWx 5.0

Thanks
Gert

-- 
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/99af5f5f-3f49-441d-acf0-e4006a1e734fn%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/99af5f5f-3f49-441d-acf0-e4006a1e734fn%40googlegroups.com?utm_medium=email_source=footer>.


-- 
You received th

Re: [weewx-user] Re: GW1000 Ecowitt Gateway and WeeWx 5.0

2023-08-15 Thread 'Rainer Lang' via weewx-user

I think a simple solution could be to extract the file gw1000.py from 
the gw1000-0.5.0b5.tar.gz archive and copy it to /usr/share/weewx/user


On 15.08.2023 10:42, gert.a...@gmail.com wrote:

Hi Ian
Thanks for looking.
I used this command to install WeeWx:

sudo apt install ./python3-weewx_5.0.0a24-a_all.deb


and this command to install GW1000


sudo weectl extension install 
https://github.com/gjr80/weewx-gw1000/releases/download/v0.5.0b5/gw1000-0.5.0b5.tar.gz



From syslog:

Aug 15 10:36:01 raspberrypi weewx[677] INFO weewx.engine: Loading 
station type GW1000 (user.gw1000)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__: Caught 
unrecoverable exception:
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:   No 
module named 'user.gw1000'
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:  
 Traceback (most recent call last):
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:     File 
"/usr/share/weewx/weewxd.py", line 149, in main
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:      
 engine = weewx.engine.StdEngine(config_dict)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:     File 
"/usr/share/weewx/weewx/engine.py", line 78, in __init__
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:      
 self.setupStation(config_dict)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:     File 
"/usr/share/weewx/weewx/engine.py", line 105, in setupStation
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:      
 __import__(driver)
Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:  
 ModuleNotFoundError: No module named 'user.gw1000'

Aug 15 10:36:01 raspberrypi weewx[677] CRITICAL __main__:   Exiting.
Aug 15 10:36:01 raspberrypi systemd[1]: weewx.service: Main process 
exited, code=exited, status=1/FAILURE
Aug 15 10:36:01 raspberrypi systemd[1]: weewx.service: Failed with 
result 'exit-code'.



I have attached the weewx.conf file


Gert




On Tuesday, August 15, 2023 at 8:52:05 AM UTC+2 Ian Millard wrote:

How did you attempt the install? I am running version 5 with a pip
installation. I am also running the Gateway driver and it
installed seamlessly using weectl extension install [URL]

Sent from my iPad.


On 15 Aug 2023, at 05:57, gert.a...@gmail.com
 wrote:

Hi Vince
I followed the installation guide for the driver, but the
installation used the folder structure from WeeWx version 4.

Rgds
Gert

On Tuesday, August 15, 2023 at 1:44:12 AM UTC+2 vince wrote:

sure why wouldn't it be ?

On Monday, August 14, 2023 at 2:03:23 PM UTC-7
gert.a...@gmail.com wrote:

Hi
Is it possible to install the gateway with WeeWx 5.0

Thanks
Gert

-- 
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/99af5f5f-3f49-441d-acf0-e4006a1e734fn%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/3cac5915-3b90-44f0-9f5d-e6e85ec506f4n%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/f8d2f335-31e4-90ce-4976-cb7be8c60f08%40gmail.com.

Re: [weewx-user] gw1000/gw2000 Battery Status

2023-08-14 Thread 'Rainer Lang' via weewx-user


@Greg
I cannot fully confirm your statements regarding HA
HA shows three different types of information regarding the Ecowitt 
battery status depending on sensor:
normal, actual voltage or percentage of charge, where in case of a WH45 
the DC connection is shown as 120%
As these different scales have historically grown, we have to live with 
the diversity.


And - my suggestion can use text for status (as the OP seems to want to do)
OFF, LOW, MED, HIGH, FULL, DC covers all situations of Ecowitt sensors 
for battery status (except for voltage)

Sensors with two status can use only OFF and FULL
the others have a 5 or 6 tier status information
those with voltage can be simply display "as is":  x.x V


On 14.08.2023 12:38, Greg Troxel wrote:

"'Rainer Lang' via weewx-user"  writes:


the driver only collects the data provided by the gateway API - and if
you have created corresponding fields and assignments, weewx stores
this data in the data base. That's it.
There is no further code as far as I am aware of.

Can you tell what exactly you want to do ?
Display the codes as human readable text e.g. in the current value
table (left side table) of the Seasons skin ?

This is really weewx-devel type content...

I'm not the OP, but for context rtl_433 has struggled with this as well.

The basic issue is that devices report battery in all sorts of ways, and
data consumers like Home Assistant and skins want a uniform
representation.  When I look at a display with battery status for a
dozen things, I don't want to think about whether they are 1 for bad and
0 for good, the other way around, 0-1 for dead to full, 0-100, 0-5 with
6 external, or something else.

The Home Assistant way is to use 0-100% with 100% full.  rtl_433's way
is to use "battery_ok" as 0-1, with 1 full/new.  These are almost the
same, with HA normier and rtl_433 nerdier (shocking!).

Home Assistant also has the concept of additional state entities which
can be labeled diagnostic to make them secondary in the UI.  Battery
level is already that (for say a water leak sensor that has a battery,
as opposed to a device whose main purpose is to measure a battery).
Things like "is this device powered by USB" isn't really battery status,
but Ecowitt has encoded it in a battery field (which is more or less ok
but it is how it is).


On 14.08.2023 08:14, Daidl Himself wrote:
I have a wh45, that gives me values 0-5 for Battery use and a 6 for
external power. Where can I find the code to validate the staus as
"OK", "BAD"or "USB" and change it accordingly?

I too have a WH45, and in Home Assistant it is showing up as 100%,
because rtl_433 reports it as 1.0.  In json it says ext_power is 1, but
I am not representing that in Home Assistant.

The rtl_433 code says:

 int battery_bars  = (b[7] & 0x40) >> 4 | (b[9] & 0xC0) >> 6;
 // A battery bars value of 6 means the sensor is powered via USB (the 
Ecowitt WS View app shows 'DC')
 int ext_power = battery_bars == 6 ? 1 : 0;
 //  Battery level is indicated with 5 bars. Convert to 0 (0 bars) to 1 (5 
or 6 bars)
 float battery_ok  = MIN(battery_bars * 0.2f, 1.0f);

which is consistent with what you say.  6 is a codepoint for external
power and contains no information about the battery.  0 is very low and
5 is great.

Note that with this encoding, if on external power you cannot tell what
the battery level is.  rtl_433 calls it 100%.  (You could argue that it
should not be reported.)

Now, what is "low?"  Hard to say, but in my world 3 will read as 60%.
If I ran this on battery, rather than just having batteries to avoid
sensor reboot and bad values when there is a power blip, then I'd know
the trajectory of a dying battery.

On a WH41, 3/60% is ok and 2/40% is a sign that trouble is coming.
1/20% is really thin ice and 0/0% indicates imminent failure.  That's
from experience with it outside with NiMH and the solar panel, which
seems to help a fresh NiMH charge last 6 months but not indefinitely any
more.

I don't meant to criticize a particular driver, but weewx might consider
adopting a regularized battery status and have each driver map into it.
I would suggest battery_ok from 0 to 1 and ext_power 0 or 1 to align
with rtl_433 since it is pretty common to get data that way, and the
world doesn't need another representation.  That could be added while
leaving the others to not mess up other processing.

Then skin code could basically say

<40% CRITICAL
<60% LOW
<80% OK

=80%FULL

or similar and use ext_power==1 to say "EXTERNAL".  The point is that it
would not have to be adapted per device, as the adaptation is from the
device into weewx.

Of course, one could argue that you want to store raw data.   So it
could certainly be both.

In Davis, at least before they went to the dark side with the 6313,
there is measured voltage for console batteries, and ISS status.
Mea

Re: [weewx-user] gw1000/gw2000 Battery Status

2023-08-14 Thread 'Rainer Lang' via weewx-user

the driver only collects the data provided by the gateway API - and if
you have created corresponding fields and assignments, weewx stores this
data in the data base. That's it.

There is no further code as far as I am aware of.

Can you tell what exactly you want to do ?
Display the codes as human readable text e.g. in the current value table
(left side table) of the Seasons skin ?

If so, you could implement the logic (code) in e.g. current.inc which is
included into index.html.tmpl at report generation time.

Something like
#if $current.wh45_bat = 0
$obs.label.wh45_bat
OFF
#else if $current.wh45_bat = 1

$obs.label.wh45_bat
LOW
#else if $current.wh45_bat = 2
.
#else

#endif

etc.

(there are more elegant versions by creating one or two internal
tables/arrays with the SET statement where you have defined all your
possible values against which you can then check in a loop, but the
above solution will also work)

On 14.08.2023 08:14, Daidl Himself wrote:

Hi,

I have the GW2000 with lots of sensors sattached, and grab the data
with the gw1000 driver. The Season skin is used to display the data.
adapting the database and the extension.py was successfull to write
the data in the database with a logical group assigned.

What I struggle with, is the logic for the Battery status for some
sensors. As mentioned in the wiki, the sensors give different values
for the status and might need to be individual configurated.

I have a wh45, that gives me values 0-5 for Battery use and a 6 for
external power. Where can I find the code to validate the staus as
"OK", "BAD"or "USB" and change it accordingly?

Re: [weewx-user] Database entries

2023-08-10 Thread 'Rainer Lang' via weewx-user

If the predefined unit of a database field changes (i.e. you want it to 
be changed), weewx needs to be told how to interprete the value stored 
in this field.
Entries in extensions.py will override the default unit definitions 
weewx keeps in a table at runtime (the obs_group_dict).


E.g.
you have more than 4 soil moisture sensors
SM1 - SM4 you can simply assign to the wsview_extended database field 
soilMoist1-4
but you have 6 SM sensors and want to use the soilTemp1-2 fields to 
store the values
be it via a field_map_extension or via an assignment in [StdCalibrate] 
[[Corrections]]


the default unit for SoilTemp1 is degree_celsius - you want it to be 
percent, you enter in extensions.py

weewx.units.obs_group_dict['soilTemp1'] = 'group_percent'

you have to make an entry for each database field whose unit 
interpretation you want to change

weewx.units.obs_group_dict['soilTemp2'] = 'group_percent'
as you want to use the database fields SoilTemp1 and SoilTemp2, but 
don't want °C to be shown in the reports


so it's always the database field name

in the above example - the default unit for soilMoisture1-4 is cb 
(centibar) which is the unit group "group_moisture" - you may want it to 
be percent as we did for SM5-6

then you will have to add 4 entries to extensions.py
weewx.units.obs_group_dict['soilMoist1'] = 'group_percent'
weewx.units.obs_group_dict['soilMoist2'] = 'group_percent'
weewx.units.obs_group_dict['soilMoist3'] = 'group_percent'
weewx.units.obs_group_dict['soilMoist4'] = 'group_percent'

If you have only 2 WH51 and want to display their readings in percent, 
you only need the first two entries


now you should know which field name to put in extensions.py for your 
WH51 battery status ... 


changes in extensions.py become only effective after a restart of weewx !

On 10.08.2023 17:06, Daidl Himself wrote:

Hi,

thats sounds good, and sqlightbrowser tells me the BatterieStatus 
fiels are empty, most likely a type mismatch as you say.
Just wonder, if I map wh51_ch1_batt to /BatteryStatus2/,  I need to 
mention /BatteryStatus2/ in extension.py. righ?




Rainer Lang schrieb am Donnerstag, 10. August 2023 um 12:51:54 UTC+2:

in principle all seems to be correct in weewx.conf

now, how to check the database: get yourself the sqlitebrowser and
look it up yourself

sudo apt-get install sqlitebrowser

 you will have to load your database and you can see everything,
all records etc.

but you may have a unit problem as the Ecowitt battery status
comes over either as integer values (0, 1, 2, 3) or as voltage
e.g. 1.64

As far as I know Gary has described this in the Ecowitt Gateway WiKi

therefore the units to be used (which may be different from
wsview_extended schema) need to be added to
extensions.py

https://github.com/gjr80/weewx-gw1000/wiki/Sensor-battery-states

and make sure you have the respective entries in your extension.py

e.g.
weewx.units.obs_group_dict['wh51_ch1_batt'] = 'group_volt'
weewx.units.obs_group_dict['wn34_ch1_batt'] = 'group_volt'

and
weewx.units.obs_group_dict['wh31_ch1_batt'] = 'group_count'
etc.

the signal levels should also belong to group_count

try that ...


On 10.08.2023 10:48, Daidl Himself wrote:

Hi,
I got a GW2000 and several sensors and use them with the gw1000
driver. So far so good, the most temeratures and stuff is
automatically logged fine.
But, I would like to see trends from the battery values as well.
Searching in the manuals let me learn, the data needs to be
mapped to a field, either creating new ones, or map to existing
ones, which are "free". So, I checked the
"schemas.wview_extended.schema" that is used an made some
mappings in the weewx.conf:


/[GW1000]
    # This section is for the Ecowitt Gateway driver.

    # How often to poll the API, default is every 20 seconds:
    poll_interval = 20

    # The driver to use:
    driver = user.gw1000
    ip_address = 192.168.179.113
    port = 45000

    show_all_batt = True

    [[field_map_extensions]]

        extraTemp8 = temp9
        rain = p_rain
        stormRain = p_rainevent
        rainRate = p_rainrate
        dayRain = p_rainday
        weekRain = p_rainweek
        monthRain = p_rainmonth
        yearRain = p_rainyear
        BatteryStatus1 = ws90_batt
        BatteryStatus2 = wh51_ch1_batt
        BatteryStatus3 = wh51_ch2_batt
        BatteryStatus4 = wn34_ch1_batt
BatteryStatus5 = wh45_batt
BatteryStatus6 = wh75_ch1_batt
    signal1 = ws90_sig
    signal2 = wh51_ch1_sig
    signal3 = wh51_ch2_sig
    signal4 = wn34_ch1_sig
    signal5 = wh45_sig
    signal6 = wh31_ch1_sig
    signal7 = wh31_ch2_sig
    signal8 = wh31_ch3_sig/

The Temperature and the rain data is all fine, but the battery

Re: [weewx-user] Database entries

2023-08-10 Thread 'Rainer Lang' via weewx-user

in principle all seems to be correct in weewx.conf

now, how to check the database: get yourself the sqlitebrowser and look
it up yourself

sudo apt-get install sqlitebrowser

you will have to load your database and you can see everything, all
records etc.

but you may have a unit problem as the Ecowitt battery status comes over
either as integer values (0, 1, 2, 3) or as voltage e.g. 1.64

As far as I know Gary has described this in the Ecowitt Gateway WiKi

therefore the units to be used (which may be different from
wsview_extended schema) need to be added to

extensions.py

https://github.com/gjr80/weewx-gw1000/wiki/Sensor-battery-states

and make sure you have the respective entries in your extension.py

e.g.
weewx.units.obs_group_dict['wh51_ch1_batt'] = 'group_volt'
weewx.units.obs_group_dict['wn34_ch1_batt'] = 'group_volt'

and
weewx.units.obs_group_dict['wh31_ch1_batt'] = 'group_count'
etc.

the signal levels should also belong to group_count

try that ...

On 10.08.2023 10:48, Daidl Himself wrote:

Hi,
I got a GW2000 and several sensors and use them with the gw1000
driver. So far so good, the most temeratures and stuff is
automatically logged fine.
But, I would like to see trends from the battery values as well.
Searching in the manuals let me learn, the data needs to be mapped to
a field, either creating new ones, or map to existing ones, which are
"free". So, I checked the "schemas.wview_extended.schema" that is used
an made some mappings in the weewx.conf:

/[GW1000]
# This section is for the Ecowitt Gateway driver.

# How often to poll the API, default is every 20 seconds:
poll_interval = 20

# The driver to use:
driver = user.gw1000
ip_address = 192.168.179.113
port = 45000

show_all_batt = True

[[field_map_extensions]]

extraTemp8 = temp9
rain = p_rain
stormRain = p_rainevent
rainRate = p_rainrate
dayRain = p_rainday
weekRain = p_rainweek
monthRain = p_rainmonth
yearRain = p_rainyear
BatteryStatus1 = ws90_batt
BatteryStatus2 = wh51_ch1_batt
BatteryStatus3 = wh51_ch2_batt
BatteryStatus4 = wn34_ch1_batt
BatteryStatus5 = wh45_batt
BatteryStatus6 = wh75_ch1_batt
signal1 = ws90_sig
signal2 = wh51_ch1_sig
signal3 = wh51_ch2_sig
signal4 = wn34_ch1_sig
signal5 = wh45_sig
signal6 = wh31_ch1_sig
signal7 = wh31_ch2_sig
signal8 = wh31_ch3_sig/

The Temperature and the rain data is all fine, but the battery data
can be shown as $latest and $current, but the image generator just
produced empty fields. Looks for me, as the "BatteryStatus" fields are
not storred in the database. How can I advice this, and how can I
check if there are already part of a group (I would guess energy would
make sense, as the value is Volt)

thanks a lot by the way, for this fantastic peace of software and user
friendly documentation.

[weewx-user] interceptor driver, HP2560 and WS90 [2]

2023-08-06 Thread 'Rainer Lang' via weewx-user

you may also want to replace your "extensions.py" by the attached one to 
have the proper units for all sensors


it also goes into /usr/share/weewx/user



 Forwarded Message 
Subject:Re: [weewx-user] interceptor driver, HP2560 and WS90
Date:   Sun, 6 Aug 2023 19:20:24 +0200
From:   Rainer Lang 
To: weewx-user@googlegroups.com



this is normal as the standard interceptor.py code doesn't have a 
complete label map to handle these labels 

Matthew hasn't found the time to extend it - others had to do this

try the attached one (interceptor.py) instead (save yours before) - it 
covers all known Ecowitt sensors as per today - it should work


it has to go to /usr/share/weewx/user


On 06.08.2023 19:06, Darkmage wrote:
So my settings were close to that one, and with some tweaking from 
what you posted, I've gotten further, I think. I'm now getting this 
from syslog:


Aug  6 13:04:56 raspberrypi weewx[18619] INFO weewx.restx: 
Wunderground-RF: Published record 2023-08-06 13:04:55 EDT (1691341495)
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter b'PASSKEY={hex string hidden in case it's for 
security}
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter runtime=4
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter rrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter erain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter hrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter drain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter wrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter mrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter yrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter ws90cap_volt=5.3
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter ws90_ver=133
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain10_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain20_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain30_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain40_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain50_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter wh90batt=3.16
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter interval=16'

--
Jason Marshall Thomas


On Sun, Aug 6, 2023 at 11:15 AM 'Rainer Lang' via weewx-user 
 wrote:


in my understanding you don't need this field map extension below
as it is already contained in the interceptor.py (driver).

The only extension you need is
[[sensor_map_extensions]]


          rain = drain_piezo
          rainRate = rrain_piezo
          supplyVoltage = wh90batt

referenceVoltage = ws90cap_volt

does your console have the proper entries in the Customized
section (WS View Plus or WebUI [https://ip-address]) ?

weewx.conf  Ecowitt console resp. WS View Plus Weather Services -
Customized
[station]   Enable
station_type = Interceptor  protocol type same as: Ecowitt
[Interceptor]   ServerIP/Hostname: 192.168.8.15 (IP address of the
computer/Server, on which weewx runs)
mode = listen   Path: /
device_type = ecowitt-client
port =  #(z.B. 8000)Port:  (the same port number as in
weewx.conf in the [Interceptor] Stanza)
iface = eth0 # bzw. wlan0   Upload Interval: 16


On 04.08.2023 21:04, Jason Thomas wrote:

Here's my entire interceptor driver output, if it helps.

raw data:

b'PASSKEY==EasyWeatherPro_V5.1.1=4=2023-08-04+19:01:54=73.2=47=29.229=29.229=91.6=41=246=4.03=4.25=8.72=817.36=7_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_volt=5.4_ver=133_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00=3.14=915M=HP2564BU_Pro_V1.9.0=30'
raw packet: {'dateTime': 1691175714, 'usUnits': 1,
'temperature_in': 73.2, 'humidity_in': 47.0, 'pressure': 29.229,
'temperature_out': 91.6, 'humidity_out': 41.0, 'wind_dir': 246.0,
'wind_speed': 4.03, 'wind_gust': 4.25, 'solar_radiation': 817.36,
'uv': 7.0}
mapped packet: {'dateTime': 1691175714, 'usUnits': 1, 'pressure':
29.229, 'outHumidity': 41.0, 'inHumidity': 47.0, 'outTemp': 91.6,
'inTemp': 73.2, 'windSpeed': 4.03, 'windGust': 4.25, 'windDir':

Re: [weewx-user] interceptor driver, HP2560 and WS90

2023-08-06 Thread 'Rainer Lang' via weewx-user

this is normal as the standard interceptor.py code doesn't have a 
complete label map to handle these labels 

Matthew hasn't found the time to extend it - others had to do this

try the attached one (interceptor.py) instead (save yours before) - it 
covers all known Ecowitt sensors as per today - it should work


it has to go to /usr/share/weewx/user


On 06.08.2023 19:06, Darkmage wrote:
So my settings were close to that one, and with some tweaking from 
what you posted, I've gotten further, I think. I'm now getting this 
from syslog:


Aug  6 13:04:56 raspberrypi weewx[18619] INFO weewx.restx: 
Wunderground-RF: Published record 2023-08-06 13:04:55 EDT (1691341495)
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter b'PASSKEY={hex string hidden in case it's for 
security}
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter runtime=4
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter rrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter erain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter hrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter drain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter wrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter mrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter yrain_piezo=0.000
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter ws90cap_volt=5.3
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter ws90_ver=133
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain10_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain20_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain30_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain40_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter gain50_piezo=1.00
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter wh90batt=3.16
Aug  6 13:05:12 raspberrypi weewx[18619] INFO user.interceptor: 
unrecognized parameter interval=16'

--
Jason Marshall Thomas


On Sun, Aug 6, 2023 at 11:15 AM 'Rainer Lang' via weewx-user 
 wrote:


in my understanding you don't need this field map extension below
as it is already contained in the interceptor.py (driver).

The only extension you need is
[[sensor_map_extensions]]


          rain = drain_piezo
          rainRate = rrain_piezo
          supplyVoltage = wh90batt

referenceVoltage = ws90cap_volt

does your console have the proper entries in the Customized
section (WS View Plus or WebUI [https://ip-address]) ?

weewx.conf  Ecowitt console resp. WS View Plus Weather Services -
Customized
[station]   Enable
station_type = Interceptor  protocol type same as: Ecowitt
[Interceptor]   ServerIP/Hostname: 192.168.8.15 (IP address of the
computer/Server, on which weewx runs)
mode = listen   Path: /
device_type = ecowitt-client
port =  #(z.B. 8000)Port:  (the same port number as in
weewx.conf in the [Interceptor] Stanza)
iface = eth0 # bzw. wlan0   Upload Interval: 16


On 04.08.2023 21:04, Jason Thomas wrote:

Here's my entire interceptor driver output, if it helps.

raw data:

b'PASSKEY==EasyWeatherPro_V5.1.1=4=2023-08-04+19:01:54=73.2=47=29.229=29.229=91.6=41=246=4.03=4.25=8.72=817.36=7_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_volt=5.4_ver=133_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00=3.14=915M=HP2564BU_Pro_V1.9.0=30'
raw packet: {'dateTime': 1691175714, 'usUnits': 1,
'temperature_in': 73.2, 'humidity_in': 47.0, 'pressure': 29.229,
'temperature_out': 91.6, 'humidity_out': 41.0, 'wind_dir': 246.0,
'wind_speed': 4.03, 'wind_gust': 4.25, 'solar_radiation': 817.36,
'uv': 7.0}
mapped packet: {'dateTime': 1691175714, 'usUnits': 1, 'pressure':
29.229, 'outHumidity': 41.0, 'inHumidity': 47.0, 'outTemp': 91.6,
'inTemp': 73.2, 'windSpeed': 4.03, 'windGust': 4.25, 'windDir':
246.0, 'radiation': 817.36, 'UV': 7.0}

I'm missing something. I have the driver configured as such:
[Interceptor]
    driver = user.interceptor
    device_type = ecowitt-client
    port = 8001
    ...
    [[sensor_map_extensions]]
        inTemp = temperature_in
        inHumidity = humidity_in
        outTemp = temperature_out

Re: [weewx-user] interceptor driver, HP2560 and WS90

2023-08-06 Thread 'Rainer Lang' via weewx-user

in my understanding you don't need this field map extension below as it 
is already contained in the interceptor.py (driver).


The only extension you need is
[[sensor_map_extensions]]


          rain = drain_piezo
          rainRate = rrain_piezo
          supplyVoltage = wh90batt

          referenceVoltage = ws90cap_volt

does your console have the proper entries in the Customized section (WS 
View Plus or WebUI [https://ip-address]) ?


weewx.conf 	Ecowitt console resp. WS View Plus Weather Services - 
Customized

[station]   Enable
station_type = Interceptor  protocol type same as: Ecowitt
[Interceptor] 	ServerIP/Hostname: 192.168.8.15 (IP address of the 
computer/Server, on which weewx runs)

mode = listen   Path: /
device_type = ecowitt-client
port =  #(z.B. 8000) 	Port:  (the same port number as in 
weewx.conf in the [Interceptor] Stanza)

iface = eth0 # bzw. wlan0   Upload Interval: 16


On 04.08.2023 21:04, Jason Thomas wrote:

Here's my entire interceptor driver output, if it helps.

raw data: 
b'PASSKEY==EasyWeatherPro_V5.1.1=4=2023-08-04+19:01:54=73.2=47=29.229=29.229=91.6=41=246=4.03=4.25=8.72=817.36=7_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_piezo=0.000_volt=5.4_ver=133_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00_piezo=1.00=3.14=915M=HP2564BU_Pro_V1.9.0=30'
raw packet: {'dateTime': 1691175714, 'usUnits': 1, 'temperature_in': 
73.2, 'humidity_in': 47.0, 'pressure': 29.229, 'temperature_out': 
91.6, 'humidity_out': 41.0, 'wind_dir': 246.0, 'wind_speed': 4.03, 
'wind_gust': 4.25, 'solar_radiation': 817.36, 'uv': 7.0}
mapped packet: {'dateTime': 1691175714, 'usUnits': 1, 'pressure': 
29.229, 'outHumidity': 41.0, 'inHumidity': 47.0, 'outTemp': 91.6, 
'inTemp': 73.2, 'windSpeed': 4.03, 'windGust': 4.25, 'windDir': 246.0, 
'radiation': 817.36, 'UV': 7.0}


I'm missing something. I have the driver configured as such:
[Interceptor]
    driver = user.interceptor
    device_type = ecowitt-client
    port = 8001
    ...
    [[sensor_map_extensions]]
        inTemp = temperature_in
        inHumidity = humidity_in
        outTemp = temperature_out
        outHumidity = humidity_out
        dateTime = dateTime
        usUnits = usUnits
        pressure = pressure
        windDir = wind_dir
        windSpeed = wind_speed
        UV = uv

And data doesn't seem to be flowing into Weewx. I guess I could start 
over completely with my weewx config - this was previously running a 
USB-connected Acurite. I was hoping I could comment that out and put 
this in and it work.


On Tuesday, June 13, 2023 at 8:26:36 PM UTC-4 Jason Gibson wrote:

Hi Rainer,

Thanks for your reply.

Rainfall data priority is set to piezo.

Standalone interceptor driver output below:

mapped packet: {'dateTime': 1686696648, 'usUnits': 1, 'pressure':
29.604, 'outHumidity': 85.0, 'inHumidity': 40.0, 'outTemp': 50.7,
'inTemp': 73.4, 'windSpeed': 8.5, 'windGust': 11.18, 'windDir':
279.0, 'radiation': 71.59, 'UV': 0.0}

It seems that I had mapped the rain fields sort of correctly. 
Although I am not sure 'rain' and 'drain_piezo' are actually the
same quantity.  There does not appear to be an equivalent to the
database field 'rain' in the output from the HP2560.  It has only
rain rate, daily, weekly, monthly and yearly rain totals.  Not
rain since last interval, which is my understanding of what the
database fieldname 'rain' is meant to represent.

Having looked at the wview-extended.py schema I can see that I had
the wrong database field names for the battery values.   I have
since changed the mapping as seen below, still no rain or battery
data.

[[sensor_map_extensions]]

          rain = drain_piezo
          rainRate = rrain_piezo
          supplyVoltage = wh90batt
          referenceVoltage = ws90cap_volt

Not sure where to go from here.

Cheers,

Jason

On Wednesday, June 14, 2023 at 3:41:00 AM UTC+10 Rainer Lang wrote:

Hi Jason

1. the local API (local Ecowitt Gateway API aka GW1000 API)
was never implemented in the HP25x0, HP350x, WH2910 consoles
=> so no such thing like depreciation
you want to know which console supports which API, look up
https://www.wxforum.net/index.php?topic=40730.0 

2. the reason why you may not receive WS90 (piezo rain) data
via the custom server could be that your WS90 has not been set
in the console as primary rain device.
gear wheel --> setup (more) --> rain priority (has to be set
to piezo).

3. could you run the interceptor driver stand-alone and post
here the result of one console post ?
(or run weewx in debug = 3 mode and copy from the syslog)

regards

Rainer

On 13.06.2023 02:28, Jason Gibson wrote:

Hi All,

I have been trying to coax rain data out of

Re: [weewx-user] WeeWX in an RV?

2023-07-29 Thread 'Rainer Lang' via weewx-user

your location data you can get out of weewx 

On 29.07.2023 22:11, Stefan Gliessmann wrote:
That would work. But I would miss out on the location and elevation
data … I would like to include location in a database …

p q schrieb am Sa. 29. Juli 2023 um 20:25:

Why not use the same one and send the temp/rH via MQTT to your
main system, since you have connectivity. You can use one of the
ExtraTemps and there's probably something suitable for rH.

On Sat, Jul 29, 2023 at 10:49 AM Stefan Gliessmann
wrote:

Dear all -

I was googling this topic without any results. So, I came here
to see, if anybody did this already.

Since ever I have a weewx installation running at home, I
would like to built a second one in my RV with probably just
temps in/out, humidity in/out and air pressure. The RV has
4G/5G internet connection and plenty of power to run a RPi ...

Any experiences with updating the station locations
automatically in weewx.conf? Anything else seems to be
straight forward ...

Cheers,
Stefan

--
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/97dea70f-9a2e-422d-a25b-924011308c35n%40googlegroups.com

--
Peter Quinn

(415)794-2264
--
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/Fwd1BvCfCoM/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/CAA1SM22tJ81-cEEcFrpK6yD%2BOoqjnLB7CsJbvr8HRnZ%2BPMdo6w%40mail.gmail.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/CACXWM9Q7vSQ%3DvyPm0Uvpw9t7u0Uz3ajzuvSTNYKC3OimW-0-6w%40mail.gmail.com
.

Re: [weewx-user] Re: WeeWX in an RV?

2023-07-29 Thread 'Rainer Lang' via weewx-user

You can get a GW1100 which comes already with an inbuilt indoor T/H
sensor, a WH32 outdoor for the outdoor T/H and maybe, if you need more,
another WH31 extra T/H sensor.
An external 3-in-1 sensor doesn't exist in the Ecowitt universe. Indoor,
yes, but a GW1100 cannot receive it.
And then run weewx on a RPi with the Ecowitt Gateway driver (aka GW1000
driver).

As you seem to be German (or from a German speaking country), I
recommend you read the very elaborated Ecowitt Weather station WiKi at
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen

There you find all available Ecowitt sensors, their combination
possibilities and all available consoles/gateways

On 29.07.2023 22:01, Stefan Gliessmann wrote:
There is no real reason why other then having historical record of
weather where I was …

I am thinking of the Ecowitt GW-1100 with an external 3-in-1 sensor or
this one
https://www.amazon.de/dp/B06X3YDSVS?psc=1=A29AHYTNE2R6PE_=chk_typ_imgToDp

which should be compatible with the Ecowitt infrastructure.

When updating the location, forecasts should be also updated within
skins like Belchertown.

vince schrieb am Sa. 29. Juli 2023 um 20:44:

On Saturday, July 29, 2023 at 10:49:14 AM UTC-7 Stefan Gliessmann
wrote:

Any experiences with updating the station locations
automatically in weewx.conf? Anything else seems to be
straight forward ...

Why do you need to update the location at all ? What is your goal
for displaying the data ? Do you need to upload somewhere and/or
have a db of historical data (ie, do you really even need weewx) ?
And of course what's your budget ?

Picking a random Ecowitt product it's under a $50 thing if you
just want a small display and a sensor or two with no internet
required...
(https://shop.ecowitt.com/products/wn2810)

--
You received this message because you are subscribed to a topic in

https://groups.google.com/d/msgid/weewx-user/d033aa60-76a0-44e0-9009-3398ac0d65c4n%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/CACXWM9ROvh-bmCSMYctgS8J5%3Db5_yes-_0%2BV7ANgSyJp7YzNrA%40mail.gmail.com
.

Re: [weewx-user] Getting 4.5.1 to upload plots from ImageGenerator to my web page

2023-07-27 Thread 'Rainer Lang' via weewx-user

You probably gave your new plot a new different name - and have
forgotten to display it also in index.html.tmpl 

On 27.07.2023 20:13, DR wrote:
I have had 4.5.1 running on a Rasp Pi 4 for over a half a year. Not a
glitch.

I wanted to add to the Seasons Skin an additional plot. The stock
package gives me the bar graph of the rain each hour.

I wanted to also have the more traditional accumulation line graph
showing the upward progression of rain (all theoretical lately with
our drought), so I copied the one that was working, then modified it a
little to produce the graph.

Despite having done this, whenever I either go to index.html in the
/var/... directory, or look at the page that WeeWx is FTPing to my web
server, I don't see the new graph.

When I look at the .png plots that are ein the directory, the
correctly named one is there, it has the (flat) graph, and the bottom
listing show the right date, time and all, so I am pretty sure it is
changing because I check at various times through the day, and it
agrees with the .png plots that are being uploaded.

Having produced the plot from ImageGenerator, is there some other
action I need to take to tell WeeWx to actually upload the plot to my
webserver?

If I modify the original rain plot with bar graphs to some slight
cosmetic change, THAT does go to my web page, so I assume there must
be, somewhere, a list of .pngs to upload?

Can someone give me a hint? Dale

Re: [weewx-user] Re: Understanding Weewx new method of logging

2023-07-27 Thread 'Rainer Lang' via weewx-user

you are free to do whatever you want...
You can even disable the rsyslog service completely and have no logging
at all.
However, turning off logging is not a very smart approach, and thinking
you can turn logging on again "when it's needed" is imho rather naive
thinking. When an application (and it may even fail to restart) fails,
you may no longer be able to find out what has caused the issue without
logs.
You can use RAM (temporary file system) as suggested by @vince, you can
move the logs to a remote server (e.g. NAS) etc., but switching off
logging completely is nothing a professional IT person would recommend

you could also use a SSD disk instead of a microSD with your RPi or a
SLC microSD card if you want to avoid wear out of your SD card ...
I'm using both approaches for years now with my RPi's - and have my logs
available in case they are needed 

On 27.07.2023 12:18, Tomasz Lewicki wrote:
Thank you. I'm using log2ram so I think it has the same effect. But I
think that some mechanism to completely turn off logging does/should
exist. I can always turn it on if needed.

I don't know if it is good approach but I've used
"disable_existing_loggers = True" directive in weewx.conf and log
aren't generated - or I can't find them :)

środa, 26 lipca 2023 o 17:50:53 UTC+2 vince napisał(a):

I just log to tmpfs (essentially ramdisk) and it is not an issue
for me.

Add this to your /etc/fstab and reboot

# put logs and tmp dirs in ramdisk ---
tmpfs /tmp tmpfs
defaults,nosuid,mode=0755,nodev,noatime 0 0
tmpfs /var/log tmpfs
defaults,nosuid,mode=0755,nodev,noatime 0 0
tmpfs /var/tmp tmpfs
defaults,nosuid,mode=0755,nodev,noatime 0 0
#-

Note that the result here is that you will lose 'all' logs when
you reboot, but the upside is it never writes to SD card. In this
configuration your pi SD is close to read-only.

On Wednesday, July 26, 2023 at 2:40:26 AM UTC-7 Tomasz Lewicki wrote:

Hi WX users.

I'd like to ask about logging in Weewx (I'm using version
4.10.2). To make a long story short, I'd like to completely
turn off logging by Weewx - because I'm using Raspberry Pi
with SD card and want to minimize write operations as much as
possible.

I've read article on wiki
(https://github.com/weewx/weewx/wiki/WeeWX-v4-and-logging) but
do not clearly understand new way of control logging. I'd like
to have simple switch in weewx.conf, for example
"completely_disable_logging = True" or something similar. Is
there some switch in [Logging] block as I see it in wiki? If I
change "disable_existing_loggers = False" to
"disable_existing_loggers = True", will I get the expected effect?

Re: [weewx-user] Re: GW1100-WS90 :Missing rainfall values

2023-07-24 Thread 'Rainer Lang' via weewx-user


maybe weewx is not the culprit 

did you set the piezo rain priority in your GW1100 ? (-->Rain totals --> 
Rainfall data priority --> Piezoelectric Rain Gauge)


On 24.07.2023 16:38, didier belin wrote:

Despite modifying weewx.conf , as quoted in another post


weewx.conf


poll_interval = 20
    # The driver to use:
    driver = user.gw1000
    ip_address = 192.168.X.X
    port = 45000
    [[field_map_extensions]]
        rain = p_rain
        stormRain = p_rainevent
        rainRate = p_rainrate
        dayRain = p_rainday
        weekRain = p_rainweek
        monthRain = p_rainmonth
        yearRain = p_rainyear

.

2023-07-24 16:33:21 CEST (1690209201): 'dateTime': '1690209201', 
'daymaxwind': '5.2', 'dayRain': '8.0', 'extraHumid1': '56', 
'extraHumid2': '85', 'extraHumid3': '67', 'extraTemp1': '24.9', 
'extraTemp2': '19.2', 'extraTemp3': '22.0', 'extraTemp9': '19.1', 
'inHumidity': '65', 'inTemp': '21.9', 'leafWet1': '0', 
'lightning_distance': '27', 'lightning_last_det_time': '1690191720', 
'lightning_strike_count': '0', 'lightningcount': '9', 'luminosity': 
'36350.0', 'monthRain': '43.5', 'outHumidity': '76', 'outTemp': 
'19.9', 'pm2_5': '4.0', 'pm2_51_24h_avg': '2.0', 'pressure': '997.3', 
'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '997.3', 
'soilMoist1': '41', 'stormRain': '12.1', 'usUnits': '17', 'UV': '2', 
'uvradiation': '54.0', 'weekRain': '12.4', 'wh31_ch1_batt': '0', 
'wh31_ch1_sig': '4', 'wh31_ch2_batt': '0', 'wh31_ch2_sig': '4', 
'wh31_ch3_batt': '0', 'wh31_ch3_sig': '4', 'wh41_ch1_batt': '4', 
'wh41_ch1_sig': '4', 'wh51_ch1_batt': '1.3', 'wh51_ch1_sig': '4', 
'wh57_batt': '5', 'wh57_sig': '4', 'windDir': '301', 'windGust': 
'3.2', 'windSpeed': '1.5', 'wn34_ch1_batt': '1.6', 'wn34_ch1_sig': 
'4', 'wn35_ch1_batt': '1.54', 'wn35_ch1_sig': '4', 'ws90_batt': 
'2.58', 'ws90_sig': '4', 'yearRain': '92.8'

Le lundi 24 juillet 2023 à 15:31:31 UTC+2, didier belin a écrit :

I can no longer find the rainfall values in weewx. all others are
visible via the seasons skin. Equipment used: ecowitt g1100; ws90.
sue ecowitt.net : no problem everything is
indicated. via the command.
PYTHONPATH=/usr/share/weewx python -m user.gw1000 --test-driver:ok
nothing seems to be missing.
I don't see where in weewx.conf or skin.conf, I have to go see

--
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/f3116941-04ca-4987-a23d-ba1756570540n%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/1a7d834c-f7c0-c54e-b6a8-26c36c95f7e2%40gmail.com.

Re: [weewx-user] Re: wewwx new variables

2023-07-23 Thread 'Rainer Lang' via weewx-user

the fields are oblivious of how the data stored was achieved (min, max,
avg, sum ...).
This is defined in the accumulators for the weewx field map - and if
your new variable is not contained or you want a different way from the
default accumulator behaviour, you have to add this to the [Accumulator]
stanza in weewx.conf

I suggest your study the weewx customization guide in the weewx
documentation - I think most if not all of your questions are answered
already there.
Your scenario is in principle described there - independent of the
driver. Also how and where to define new units - or assign existing ones.

https://www.weewx.com/docs

If you get stuck, come back here 

On 23.07.2023 19:24, maria gourniezaki wrote:
Thank for your response. How to distinguish between accumulative
fields and now accumulative ones?
Is this done into the weewx config file? And how about specifying the
units (KW, Joule, etc)?

M.-

On Sunday, July 23, 2023 at 8:19:14 PM UTC+3 michael.k...@gmx.at wrote:

You probably want to use wee_database --add-column
https://weewx.com/docs/latest/customizing.htm#Modifying_an_existing_database

maria gourniezaki schrieb am Sonntag, 23. Juli 2023 um 19:13:40 UTC+2:

Hi all,

I have a weewx station running using the fileparse driver for
about 4 years now.
All variables are read periodically from a memory file. Now I
want to add two additional measurements from a solar panel.
Namely I need to store (and show as respective graphs) the
current power in W and as an accumulative variable I would
like to store (and show) the generated KWh values.
My question is: do I need to add those two fields into the db
manually or is there an automatic way. Those two measurements
are already present in my fileparse file together with the
respective values.
What else should I add to the weewx config files so to define
the nature of the variables (accumulative, etc).
Please help me to complete this task
BR
Maria

Re: [weewx-user] GW1000 stopped working

2023-07-23 Thread 'Rainer Lang' via weewx-user

you have to do some proper network analysis - this whole story is 
neither a GW1000 nor a weewx issue.

And I doubt that "just out of the air" it all stopped and went wrong.
Something must have (been) changed in the network configuration.

"Upgraded the GW1000 firmware"
that means you must have used the WS View Plus app and are now on 
firmware 1.7.6
That also means that a mobile device inside your local network (your 
smartphone, tablet ...) can contact the GW1000 via port 45000 (that's 
what WS View Plus does)
The issue is then between your RPi, your router and the GW1000. I assume 
the "culprit" is your router (some of its configuration).

_Can you ping the GW1000 from your router ? _
Routers usually allow to issue/send ping and traceroute commands.
_And can you ping your RPi from your router ?_

_Have you checked if your router has some special flag/option/button/tag 
(in fact a firewall feature)
where a specific WLAN device (here your GW1000) is allowed to 
communicate with other devices in the local network ?

_I asked this already earlier but you didn't reply to the question_
_

_"_i dont know how to get the netmask of the GW1000"
the GW1000 has received its subnet information (netmask) from your 
router's DHCP server

it should be correct - it's most likely 192.168.1.1/24 (or 255.255.255.0),
and the router (the DHCP server of the router) will provide the gateway 
information and usually names itself as DNS server
This must all be correct - otherwise the GW1000 could not successfully 
post to ecowitt.net


"But  the ecowitt webpage is receiving data"

that clearly tells that the GW1100 is properly connected to your router 
and posts to the internet


"initially it wont ping then it succeeds why ??"

something (some network element) was sleeping in your local network, it 
needed the ping to wake up - these things happen


If nothing works (I don't know what your infrastructure is like - is 
your router at the same time the WLAN access point or not etc.),
but I would suggest that you connect your router directly with a LAN 
cable to the RPi
(you hopefully have a more modern one which has a LAN/Ethernet 
interface; you didn't tell us which models you use)

and see what it gives.

On 23.07.2023 20:43, zasp...@gmail.com wrote:

Hi

Laptop information

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : home
   Description . . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 
6235

   Physical Address. . . . . . . . . : B4-B6-76-01-EC-99
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.156(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 23 July 2023 10:27:09
   Lease Expires . . . . . . . . . . : 24 July 2023 10:29:13
   Default Gateway . . . . . . . . . : 192.168.1.254
   DHCP Server . . . . . . . . . . . : 192.168.1.254
   DNS Servers . . . . . . . . . . . : 127.0.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled


PI weewx
wlan0: flags=4163  mtu 1500
        inet 192.168.1.242  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::148a:46fd:4ac9:e7b0  prefixlen 64  scopeid 0x20
        inet6 2a00:23c4:9402:8f01:13da:6dac:cd41:7029  prefixlen 64 
 scopeid 0x0
        inet6 fd00::1:8d4a:e62c:d18b:de48  prefixlen 64  scopeid 
0x0

        ether dc:a6:32:38:98:da  txqueuelen 1000  (Ethernet)
        RX packets 2921761  bytes 3720208567 (3.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1849890  bytes 918345739 (875.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

PI second
wlan0: flags=4163  mtu 1500
        inet 192.168.1.94  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::f227:28d7:543b:e89f  prefixlen 64  scopeid 0x20
        inet6 fd00::1:31a3:d46c:62cc:5f7  prefixlen 64  scopeid 
0x0
        inet6 2a00:23c4:9402:8f01:7656:850a:5d26:1be2  prefixlen 64 
 scopeid 0x0
        inet6 fd00::1:36c5:e8c1:657d:d85a  prefixlen 64  scopeid 
0x0
        inet6 2a00:23c4:9402:8f01:a8f0:3a46:764a:9005  prefixlen 64 
 scopeid 0x0

        ether dc:a6:32:06:87:03  txqueuelen 1000  (Ethernet)
        RX packets 31185  bytes 28290241 (28.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18891  bytes 2106606 (2.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

i dont know how to get the netmask of the GW1000
its ip address is 192.168.1.248

i used advanced IP scanner to ping it from the laptop
Pinging 192.168.1.248 with 32 bytes of data:
Reply from 192.168.1.156: Destination host unreachable.
Request timed out.
Reply from 192.168.1.156: Destination host unreachable.
Request timed out.
Reply from 192.168.1.156: Destination host unreachable.
Request timed out.
Reply from 192.168.1.248: bytes=32 time=447ms TTL=255
Reply from 192.168.1.248: bytes=32 time=3ms TTL=255
Reply from 192.168.1.248: bytes=32 time=4ms TTL=255
Reply from

Re: [weewx-user] GW1000 stopped working

2023-07-22 Thread 'Rainer Lang' via weewx-user


the message is clear:
DEBUG user.gw1000: Failed attempt 1 to send command 
'CMD_READ_STATION_MAC': [Errno 101] _*Network is unreachable*_


_you have an issue reaching your GW1100 from the weewx server_

at first glance that's neither a weewx nor a GW1100 issue - it looks 
like an issue in your local network infrastructure.


Also, I hope that your IP address for the GW1100 is 192.168.1.248 and 
NOT, as you write, 192.168.1..248 (if in weewx.conf you have 
192.168.1..248 then that's not not a valid IP address !!
It might just be a typo (error while typing) at your end, but worth 
checking.


Can you reach your router and the GW1100 on the operating system level 
of your RPi ?


ping 192.168.1.1 would/should reach the router

ping 192.168.1.248
should reach the GW1100 unless your router has some policy active which 
doesn't allow that

or
traceroute 192.168.1.248
should give you the IP addresses of the devices (router/switch ...) on 
the network path between your device (RPi) and the destination device 
(GW1100)


Depending on which router you have, some router set by default a tag 
which doesn't allow WLAN/WiFi devices to communicate inside the local 
network - you have to explicitly allow that, often by removing a 
tagged/ticket box.


It's not impossible that your image is faulty and you might need to 
flash that image again.


On 22.07.2023 12:23, zasp...@gmail.com wrote:

hi

the ip address 192.168.1..248

has not changed its in my weewx.confg
i can log in with chrome on that address

and my router has a fixed ip for this mac address

what i dont understand is why my raspi image from 3 weeks ago will not 
work thats strange


my syslog attached

thanks for your help




On Saturday, 22 July 2023 at 09:53:09 UTC+1 Rainer Lang wrote:

can you see the live data in the WS View Plus app or in the
WebUI/embedded webpage (IP address of your GW1100 in the browser
URL field) ?

maybe the IP of your GW1100 changed, which won't keep it from
posting to ecowitt.net <http://ecowitt.net>, but if it is now
different from what is written in weewx.conf, weewx won't recieve
anything

please post the syslog of the weewx startup procedure, best for
one archive interval, so we can see what the Ecowitt Gateway
driver feedback is

did you make your IP address of the GW1100 static (WebUI, device
settings) ? - you better do !
or alternatively make a so-called IP/MAC address binding of the
current DHCP provided IP in your router
making it static from within the WebUI is in my experience the
better version, but both work
(whenever you make changes inside WS View Plus or the WebUI, make
sure you see the "success" message after pressing "save" or "apply"

On 22.07.2023 10:24, zasp...@gmail.com wrote:



 Hi

After running a GQ1000 for around 8 weeks it has stopped working
at 03:15 am so I wasn’t around at that time of the morning
fiddling. it just stopped for some reason

After it stopped reviving data

I have rebooted the GW1000 and the pi

Upgraded the GW1000 firmware

Tried the sd card in another pi

Used a backup image from 3 weeks ago that worked fine then

Weewx cant see the GW1000 nothing works

I have run

python -m user.gw1000 --test-driver

no data is being picked up, previously you could see what
information was being received

I thought maybe the GW100 had failed or not working

But  the ecowitt webpage is receiving data

Any ideas ?

Jul 22 09:06:13 raspberrypiwx weewx[771] DEBUG __main__:
Initializing engine

Jul 22 09:06:13 raspberrypiwx weewx[771] INFO weewx.engine:
Loading station type GW1000 (user.gw1000)

Jul 22 09:06:15 raspberrypiwx weewx[771] DEBUG user.gw1000:
Failed to obtain response to attempt 1 to send command
'CMD_READ_STATION_MAC': timed out

Jul 22 09:06:16 raspberrypiwx postfix/qmgr[863]: 0FFBEDF431:
from=, size=967, nrcpt=1 (queue active)

Jul 22 09:06:16 raspberrypiwx postfix/pickup[4522]: E45F4DF429:
uid=1000 from=

Jul 22 09:06:16 raspberrypiwx postfix/cleanup[7600]: E45F4DF429:
message-id=<202307220806...@raspberrypiwx.home>

Jul 22 09:06:27 raspberrypiwx weewx[771] DEBUG user.gw1000:
Failed to obtain response to attempt 2 to send command
'CMD_READ_STATION_MAC': timed out

Jul 22 09:06:39 raspberrypiwx weewx[771] DEBUG user.gw1000:
Failed to obtain response to attempt 3 to send command
'CMD_READ_STATION_MAC': timed out

Jul 22 09:06:39 raspberrypiwx weewx[771] ERROR user.gw1000:
Failed to obtain response to command 'CMD_READ_STATION_MAC' after
3 attempts

Jul 22 09:06:39 raspberrypiwx weewx[771] ERROR weewx.engine:
Import of driver failed: Failed to obtain response to command
'CMD_READ_STATION_MAC' after 3 attempts ()

Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL
weewx.engine:       Traceback (mo

Re: [weewx-user] GW1000 stopped working

2023-07-22 Thread 'Rainer Lang' via weewx-user

can you see the live data in the WS View Plus app or in the 
WebUI/embedded webpage (IP address of your GW1100 in the browser URL 
field) ?


maybe the IP of your GW1100 changed, which won't keep it from posting to 
ecowitt.net, but if it is now different from what is written in 
weewx.conf, weewx won't recieve anything


please post the syslog of the weewx startup procedure, best for one 
archive interval, so we can see what the Ecowitt Gateway driver feedback is


did you make your IP address of the GW1100 static (WebUI, device 
settings) ? - you better do !
or alternatively make a so-called IP/MAC address binding of the current 
DHCP provided IP in your router
making it static from within the WebUI is in my experience the better 
version, but both work
(whenever you make changes inside WS View Plus or the WebUI, make sure 
you see the "success" message after pressing "save" or "apply"


On 22.07.2023 10:24, zasp...@gmail.com wrote:



 Hi

After running a GQ1000 for around 8 weeks it has stopped working at 
03:15 am so I wasn’t around at that time of the morning fiddling. it 
just stopped for some reason


After it stopped reviving data

I have rebooted the GW1000 and the pi

Upgraded the GW1000 firmware

Tried the sd card in another pi

Used a backup image from 3 weeks ago that worked fine then

Weewx cant see the GW1000 nothing works

I have run

python -m user.gw1000 --test-driver

no data is being picked up, previously you could see what information 
was being received


I thought maybe the GW100 had failed or not working

But  the ecowitt webpage is receiving data

Any ideas ?

Jul 22 09:06:13 raspberrypiwx weewx[771] DEBUG __main__: Initializing 
engine


Jul 22 09:06:13 raspberrypiwx weewx[771] INFO weewx.engine: Loading 
station type GW1000 (user.gw1000)


Jul 22 09:06:15 raspberrypiwx weewx[771] DEBUG user.gw1000: Failed to 
obtain response to attempt 1 to send command 'CMD_READ_STATION_MAC': 
timed out


Jul 22 09:06:16 raspberrypiwx postfix/qmgr[863]: 0FFBEDF431: 
from=, size=967, nrcpt=1 (queue active)


Jul 22 09:06:16 raspberrypiwx postfix/pickup[4522]: E45F4DF429: 
uid=1000 from=


Jul 22 09:06:16 raspberrypiwx postfix/cleanup[7600]: E45F4DF429: 
message-id=<20230722080616.e45f4df...@raspberrypiwx.home>


Jul 22 09:06:27 raspberrypiwx weewx[771] DEBUG user.gw1000: Failed to 
obtain response to attempt 2 to send command 'CMD_READ_STATION_MAC': 
timed out


Jul 22 09:06:39 raspberrypiwx weewx[771] DEBUG user.gw1000: Failed to 
obtain response to attempt 3 to send command 'CMD_READ_STATION_MAC': 
timed out


Jul 22 09:06:39 raspberrypiwx weewx[771] ERROR user.gw1000: Failed to 
obtain response to command 'CMD_READ_STATION_MAC' after 3 attempts


Jul 22 09:06:39 raspberrypiwx weewx[771] ERROR weewx.engine: Import of 
driver failed: Failed to obtain response to command 
'CMD_READ_STATION_MAC' after 3 attempts ()


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine:    
  Traceback (most recent call last):


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/weewx/engine.py", line 119, in setupStation


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
  self.console = loader_function(config_dict, self)


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 1674, in loader


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
 return GatewayDriver(**config_dict[DRIVER_NAME])


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 2111, in __init__


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
  super(GatewayDriver, self).__init__(**stn_dict)


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 968, in __init__


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
  debug=self.debug)


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 2436, in __init__


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
 log_unknown_fields=log_unknown_fields, debug=debug)


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 5847, in __init__


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
  debug=debug)


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
    File "/home/weewx/bin/user/gw1000.py", line 4578, in __init__


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine: 
  self.mac = self.get_mac_address()


Jul 22 09:06:39 raspberrypiwx weewx[771] CRITICAL weewx.engine:  File
--
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

Re: [weewx-user] Seasons skin, multiple WH51 sensors - wrong units

2023-07-21 Thread 'Rainer Lang' via weewx-user

Assuming you assign your WH51 sensors to the SoilMoist1 thru SoilMoist4 
database fields, be via a fieldmap extension or a 
StdCalibrate/Corrections entry in weewx.conf,
you will also have to add some changes to extensions.py (in 
/usr/share/weewx/user or /home/weewx  depending on your installation):
(I also assume you are using an extended Interceptor driver for weewx to 
read the HP2551 consol posts)


*import weewx.units ***
*weewx.units.obs_group_dict['soilMoist1'] = 'group_percent'*
*weewx.units.obs_group_dict['soilMoist2'] = 'group_percent'*

for each of the four available soilMoist fields in the wsview_extended 
database schema, you will need to make such an entry
(but only if you have another WH51 sensor) if you want their readings 
shown in % rather than in cb
if you have more than four WH51 (and want to save their values in the 
database), you will either need to repurpose other not used fields in 
the wsview_extended database schema or create additional columns in your 
database e.g. by the help of the wee_database tool


(the entry/line "_import weewx.units_" needs to be there only once; if 
it's already there, you don't need to add it a second time !)


weewx needs to restarted after having made the changes to extensions.py

On 21.07.2023 17:07, paulth...@gmail.com wrote:
I bought a HP2551 weather station to replace my old, trusty but crusty 
WH3081.


I went with the Seasons skin, because it was the only one that seemed 
to recognise the  WH51 moisture sensor.  I followed some Internet 
instructions to display the WH51 readings as a percentage instead of 
"cb"; job done.


I recently bought a second WH51 sensor, and added it to weewx.conf in 
the same way (soil_moisture_percent) as the first sensor; it 
stubbornly displays as "cb".


Any ideas?

Cheers!
--
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/c2587160-ce5a-4227-afff-9959e2d55a9an%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/8d9d0c0e-c78a-92ad-ea07-6db6fab41086%40gmail.com.

[weewx-user] Re: HP1000 driver with WS-1001 clone - "HP1000: Timed out too many times"

2023-07-20 Thread 'Rainer Lang' via weewx-user

Another option I could suggest for this antiquarian piece of a weather 
station (it's imho a shame that such old hardware is still being sold - 
but probably the sellers want to empty their stock - when technology has 
made already big leaps ahead for 5+ years) would be to get yourself a 
modern Ecowitt GW1100 gateway (~35 USD) which can still receive the WH24 
outdoor array (the "boat") and have weewx read from the GW1100 via the 
Ecowitt Gateway driver which Gary has written.


https://github.com/gjr80/weewx-gw1000/wiki
The GW1100 offers an option for the legacy WH24 to be received - wind 
readings are different from the newer arrays)
(watch for the matching reception frequency, in your case probably 868 
MHz or 433 MHz).


This would also leave you open for adding other modern sensors from 
Ecowitt (provided you are interested) as it supports all recent 
available Ecowitt (clone) sensors.
An overview of the Ecowitt universe you find at 
https://www.wxforum.net/index.php?topic=40730.0


On 20.07.2023 04:29, Susan Mackay wrote:
As the author of that driver, all I can suggest is that the weather 
station is not interpreting the request correctly and therefore it is 
being ignored. Perhaps a different post is being used, or a different 
protocol??? The HP1001 manual that I found ( Microsoft Word - HP1000 
HP2000 User Manual_rev.11，3.1.19wunderground注册内容更新_.doc 
(conrad.com) 
) 
does seem to be a bit more sophisticated than the HP1000 so there may 
well be a different protocol etc.
The way I 'reverse engineered' the protocol was to use another piece 
of software (EasyWeather IIRC) that talked to the weather console. 
Perhaps if you have something like that you can see how it is trying 
to communicate with the console.
As a side note - if you have something like the RTL-SDR dongle then 
you might be able to tap into the data from the weather station to the 
console and use the RTL_433 to get it into WeeWx.
Not a satisfactory answer I know but without having one of the 
consoles to 'play' with it is hard to diagnose the problem from the 
console side.

Susan

On Thursday, 20 July 2023 at 1:11:16 am UTC+10 Tomasz Lewicki wrote:

Hi Weewx users.

Recently I bought WS-1001 clone - HP1001 made by Conrad (Germany).
Two or three years ago I've installed Weewx for my DIY weather
station so I'm familiar with this software. I'm also long time
Linux user so I'm not afraid of CLI.

So. I have working Weewx installation. I see logs (debug = 1 in
weewx.conf). I've downloaded and successfully installed HP1000
driver (https://github.com/AussieSusan/HP1000). Weewx is
reconfigured to use HP1000 driver. I know IP of my weather
station, it has static address, like many devices in my LAN. When
I start Weewx, I see in log:

weewx[13810] INFO __main__: Initializing weewx version 4.10.2
weewx[13810] INFO __main__: Using Python 3.7.3 (default, Jun 29
2023, 18:03:57) [GCC 8.3.0]
weewx[13810] INFO __main__: Located at /usr/bin/python3
weewx[13810] INFO __main__: Platform
Linux-5.10.103-v7+-armv7l-with-debian-10.13
weewx[13810] INFO __main__: Locale is 'pl_PL.UTF-8'
weewx[13810] INFO __main__: Using configuration file
/etc/weewx/weewx.conf
weewx[13810] INFO __main__: Debug is 1
weewx[13810] INFO __main__: PID file is /var/run/weewx.pid
weewx[13814] DEBUG __main__: Initializing engine
weewx[13814] INFO weewx.engine: Loading station type HP1000
(user.HP1000)
weewx[13814] INFO root: HP1000: HP1000 Starting
weewx[13814] INFO root: HP1000: Using "netifaces" to determine
broadcast mask
weewx[13814] INFO root: HP1000: Address Mask = 192.168.0.255
weewx[13814] INFO root: HP1000: Retry count = 5.00
weewx[13814] INFO root: HP1000: Socket timeout = 5.00
weewx[13814] INFO root: HP1000: Loop delay = 15.00
weewx[13814] INFO root: HP1000: Retry Wait = 5.00
weewx[13814] INFO root: HP1000: Max Retry = 3.00

But after some time a message appears:

weewx[13814] INFO root: HP1000: Timed out too many times

repeated dozens of times.

I started Wireshark to sniff the network traffic on my laptop in
the same LAN as Weewx and weather station and got this:

604.225791451192.168.0.106192.168.0.255UDP8248576 → 6000 Len=40
28224.194043968192.168.0.106192.168.0.255UDP8250680 → 6000 Len=40
51144.162213176192.168.0.106192.168.0.255UDP8237338 → 6000 Len=40

First column is packet number. Second - time of sniffing. Third -
IP of my Raspberry with Weewx (192.168.0.106). Fifth -
192.168.0.255 is broadcast address, equal to Address Mask in Weewx
log. UDP is network protocol. Sixth - packet length in bytes.
Seventh - five digits number is port number of Weewx sending the
packet; 6000 is destination port of

Re: [weewx-user] Re: Solar irradiance form ecowitt GW1100

2023-07-17 Thread 'Rainer Lang' via weewx-user

can you please post your syslog after restarting weewx with debug = 3 in
weewx.conf from the weewx restart until at least the first archiving
cycle and report generation (so it ever completes) is finished

thanks

On 17.07.2023 17:53, Stefan Gliessmann wrote:
I have read the link above and made the suggested changes, but to no
success ...

Screenshot 2023-07-17 at 17.48.08.png

Screenshot 2023-07-17 at 17.50.25.png

Screenshot 2023-07-17 at 17.51.58.png

On Sunday, January 15, 2023 at 11:43:16 PM UTC+1 Christian Schuhmann
(I__-CRaZY-__I) wrote:

Thanks!!

gjr80 schrieb am Samstag, 14. Januar 2023 um 23:52:24 UTC+1:

Yes, read this

Gary

On Sunday, 15 January 2023 at 08:46:24 UTC+10
christiansch...@gmail.com wrote:

Hello weewx friends,

my system is running in docker with weewx 4.9.1,
weewx-gw1000 driver and the Weather data center 2.3.2 skin.

I'm a complete newbie in weewx.

My ecowitt GW1100 is running with the latest firmware
V2.2.1 and not connected to any cloud services, i uploaded
only the GW1100 live data to home assistant.

Here my Live data:

Screenshot 2023-01-14 233845.png

The problem is, i see no "Solar Irradiance" in weewx
Screenshot 2023-01-14 234402.png

Can anybody help me with the weewx.conf :/

Regrads,
Chris

Re: [weewx-user] weewx can't update data from netatmo no more

2023-07-17 Thread 'Rainer Lang' via weewx-user

Maybe you send us a complete excerpt from your syslog covering the weewx
startup and at least one archiving period

That would be more helpful than just a few snippets.

Thanks

On 17.07.2023 11:02, 'neu...@bnjpro.dk' via weewx-user wrote:
I have been the happy user of weeWX for a very long time now. And I'm
still amazed that someone is able to write such a large and well
functioning piece of software. I think when you are not able to
program in python it is amazing when someone else can. :-)

Friday last week (monday today) I made an upgrade on my server (Ubuntu
22.04 LTS) to also be able to get updates from Ubuntu pro.

But after doing that, my WeeWX installation doesn't work. Well that is
not entirely true, because WeeWx works, but the driver for my netatmo
weather-station does not get data.

I use driver version 0.14 which I think is the latest, and the one
that gets data the way netatmo API wants it to. I have user, password,
client-id and client-secret running as expected.

But looking at the logfile (syslog) I get the hint that there is a
HTTP error 400. This hint is a little week for me to figure out what
is the real course of fail, to be able to do something about it.

Additionally I get this output from the log: url:
https://api.netatmo.com/oauth2/token data:
b'grant_type=password_id=64b0ea9f090b11190f07b867_secret=Haf1qozNFvLMjpjp64cSpgiuPY3IYm4BlPb8zp7EmjlL=neumann%40bnjpro.dk=SECRET=read_station'
hdr: {'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8'}

I have masked out my password.

Is there any obvious reason for the driver to not being able to
connect to the API?

Re: [weewx-user] weewx no longer running

2023-07-10 Thread 'Rainer Lang' via weewx-user


that's an option
but keep your Skin files (rename your skin directory) and weewx.conf so 
you can cannibalize on them when doing a complete new install - and, of 
course, keep your weewx.sdb  (safety copy).
You may need to download a new updated driver/extension for your 
Tempest, too.


On 10.07.2023 21:45, mukbar wrote:
It is an old system that crashed in December 2022,  due to a power 
outage, I think. I lost remote access at that time. I finally came to 
the site in Belize last week and have been trying to bring the system 
back to life with no luck. Everything on my droplet side (MQTT, etc.) 
is working, as far as I can tell. But I cannot get weewx to start. Not 
sure if it being down for 6 months has rendered recovery impossible.


Should I delete weewx and reinstall and start over? Or is there more 
troubleshooting I should do?






On Monday, July 10, 2023 at 1:25:53 PM UTC-6 vince wrote:

What did you change in your weewx system that possibly caused it
to break ?

Or is it a new system that you are trying to get to work ?

On Monday, July 10, 2023 at 11:02:24 AM UTC-7 mukbar wrote:

Thank you. Just did all that. Now says python3-pip is already
the newest version.

Forgot to mention weather station: Weatherflow Tempest

sudo weewxd now yields:

Traceback (most recent call last):
  File "/usr/share/weewx/weewxd", line 249, in 
    main()
  File "/usr/share/weewx/weewxd", line 154, in main
    engine.run()
  File "/usr/share/weewx/weewx/engine.py", line 178, in run
    self.dispatchEvent(weewx.Event(weewx.STARTUP))
  File "/usr/share/weewx/weewx/engine.py", line 245, in
dispatchEvent
    callback(event)
  File "/usr/share/weewx/weewx/engine.py", line 584, in startup
self._catchup(self.engine.console.genStartupRecords)
  File "/usr/share/weewx/weewx/engine.py", line 697, in _catchup
    for record in generator(lastgood_ts):
  File "/usr/share/weewx/user/weatherflowudp.py", line 620, in
genStartupRecords
    for packet in readDataFromWF(since_ts + 1, self._token,
self._devices, self._device_dict, self._batch_size):
  File "/usr/share/weewx/user/weatherflowudp.py", line 329, in
readDataFromWF
    raise DriverException("Could not fetch records from
WeatherFlow webservice: {}".format(response))
user.weatherflowudp.DriverException: Could not fetch records
    from WeatherFlow webservice: 

On Monday, July 10, 2023 at 11:07:23 AM UTC-6 Rainer Lang wrote:

try

sudo pip3 install --upgrade requests
if pip3 is not installed, do it before

sudo apt-get -y install python3-pip



On 10.07.2023 18:50, mukbar wrote:

Hello,

Have lurked here for years. Many folks have been
invaluable in helping me set up https://sanpedrowx.com/.

I am stuck now and need some help, please. weewx is no
longer running.

weewx version 4.10.2
installed with the debian package on Raspberry Pi 4 Model
B rev 1.4.
raspbian version: 10

Trying to start weewx with sudo weewxd with debug = 1 yields:

/usr/lib/python3/dist-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.26.7) or chardet
(3.0.4) doesn't match a supported version!
RequestsDependencyWarning)
Traceback (most recent call last):
  File "/usr/share/weewx/weewxd", line 249, in 
    main()
  File "/usr/share/weewx/weewxd", line 154, in main
    engine.run()
  File "/usr/share/weewx/weewx/engine.py", line 178, in run
self.dispatchEvent(weewx.Event(weewx.STARTUP))
  File "/usr/share/weewx/weewx/engine.py", line 245, in
dispatchEvent
    callback(event)
  File "/usr/share/weewx/weewx/engine.py", line 584, in
startup
self._catchup(self.engine.console.genStartupRecords)
  File "/usr/share/weewx/weewx/engine.py", line 697, in
_catchup
    for record in generator(lastgood_ts):
  File "/usr/share/weewx/user/weatherflowudp.py", line
620, in genStartupRecords
    for packet in readDataFromWF(since_ts + 1,
self._token, self._devices, self._device_dict,
self._batch_size):
  File "/usr/share/weewx/user/weatherflowudp.py", line
329, in readDataFromWF
    raise DriverException("Could not fetch records from
WeatherF

Re: [weewx-user] weewx no longer running

2023-07-10 Thread 'Rainer Lang' via weewx-user


try

sudo |pip3 install --upgrade requests|
|if pip3 is not installed, do it before

|

|sudo apt-get -y install python3-pip|

|
|

|
|

||

On 10.07.2023 18:50, mukbar wrote:

Hello,

Have lurked here for years. Many folks have been invaluable in helping 
me set up https://sanpedrowx.com/.


I am stuck now and need some help, please. weewx is no longer running.

weewx version 4.10.2
installed with the debian package on Raspberry Pi 4 Model B rev 1.4.
raspbian version: 10

Trying to start weewx with sudo weewxd with debug = 1 yields:

/usr/lib/python3/dist-packages/requests/__init__.py:91: 
RequestsDependencyWarning: urllib3 (1.26.7) or chardet (3.0.4) doesn't 
match a supported version!

RequestsDependencyWarning)
Traceback (most recent call last):
  File "/usr/share/weewx/weewxd", line 249, in 
    main()
  File "/usr/share/weewx/weewxd", line 154, in main
    engine.run()
  File "/usr/share/weewx/weewx/engine.py", line 178, in run
self.dispatchEvent(weewx.Event(weewx.STARTUP))
  File "/usr/share/weewx/weewx/engine.py", line 245, in dispatchEvent
    callback(event)
  File "/usr/share/weewx/weewx/engine.py", line 584, in startup
self._catchup(self.engine.console.genStartupRecords)
  File "/usr/share/weewx/weewx/engine.py", line 697, in _catchup
    for record in generator(lastgood_ts):
  File "/usr/share/weewx/user/weatherflowudp.py", line 620, in 
genStartupRecords
    for packet in readDataFromWF(since_ts + 1, self._token, 
self._devices, self._device_dict, self._batch_size):
  File "/usr/share/weewx/user/weatherflowudp.py", line 329, in 
readDataFromWF
    raise DriverException("Could not fetch records from WeatherFlow 
webservice: {}".format(response))
user.weatherflowudp.DriverException: Could not fetch records from 
WeatherFlow webservice: 


Thank you.

--
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/56b65698-3ea4-482b-8974-1a5a48c88a7bn%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/380e606e-8c9a-0906-2017-9a4aea723df4%40gmail.com.

Re: [weewx-user] Old weewx

2023-06-30 Thread Rainer Lang

What you are probably not so happy with is the new (since 4.7) Seasons
skin produced by its standard files.

What you can do is e.g.
- create a new directory under /etc/weewx/skins (or /home/weewx/skins
when you used setup.py)
with the name Seasons-Old (sudo mkdir /home/weewx/skins/Seasons-Old )
and copy all your files from your old installation

(/home/weewx/skins/Seasons) into that directory.
- by changing the skin name entry in weewx.conf in the [StdReport]
[[SeasonsReport]] stanza from
skin = Seasons to skin = Seasons-Old (then restart weewx), you should
get your old view back again

if that is what you are looking for
On 30.06.2023 06:15, Ian Boag wrote:
I have a weewx installation running ust fine under an ancient DietPi
OS. So ancient that I can't update the OS. So I have configured up a
new card with PiOS.

I went through the apt install for weewx and found it was all a bit
more different than I was happy with

Is there any way I can get a weewx 3.1.0 to install?

I sort of wondered about a brutal approach of cloning the home/weewx
folder (which is my weewx root) and the init.d/weewx entry
showing my ignorance :-)

I can downgrade the python3 to python2 if that is necessary

Cheers IB
--
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/aff1560e-fc1f-4ce4-9730-9fe884e687e2n%40googlegroups.com
.

Re: [weewx-user] Re: weather station for 400-600 Euros

2023-06-29 Thread Rainer Lang

 21:52:40 weewx weewx[3132] INFO weewx.wxservices: 
StdWXCalculate will use data binding wx_binding


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: Archive will use 
data binding wx_binding


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: Record generation 
will be attempted in 'software'


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: Using archive 
interval of 120 seconds (software record generation)


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: StationRegistry: 
Station will be registered.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: Wunderground: No 
config info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: PWSweather: No 
config info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: CWOP: No config 
info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: WOW: No config 
info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: AWEKAS: No config 
info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO user.wetter: service version is 0.7

Jun 28 21:52:40 weewx weewx[3132] INFO user.wetter: wetter API version 
is 5.0.2 - 2015/06/01


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.restx: Wetter: No config 
info. Skipped.


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: 'pyephem' 
detected, extended almanac data is available


Jun 28 21:52:40 weewx weewx[3132] INFO __main__: Starting up weewx 
version 4.10.2


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.manager: Starting 
backfill of daily summaries


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.manager: Daily summaries 
up to date


Jun 28 21:52:40 weewx weewx[3132] INFO weewx.engine: Starting main 
packet loop.



But that's all and there are no entries about weewx recieving data 
from the console.


How can I get weewx to recieve data from the console?

Thank you for your help!
metalmi...@gmail.com schrieb am Donnerstag, 22. Juni 2023 um 21:00:35 
UTC+2:


Yes, the guy in the German forum told me already.

Pretty smart, these Ecowitt consoles. :D

Rainer Lang schrieb am Donnerstag, 22. Juni 2023 um 20:55:21 UTC+2:

and that's more than enough for the Ecowitt console(s) to post
their data to weewx 
(apart from the possibility to introduce specific firewall
rules on specific ports )

On 22.06.2023 20:52, metalmi...@gmail.com wrote:

Because the server is in a different subnet than my LAN.

Let's say the server is in the 10.10.20.0/24
<http://10.10.20.0/24> net and on my LAN I have the
10.10.10.0/24 <http://10.10.10.0/24> net. A demilitarized
zone (DMZ) has only access to the internet and to no other
net. A Firewall rule blocks outgoing connections from the DMZ
to all other nets, exept the internet. So from the VM I have
no access to my LAN, where the console would be. *The other
way round is possible, from my LAN network I have full access
to all machines and services in the DMZ. **
    *
    Rainer Lang schrieb am Donnerstag, 22. Juni 2023 um 20:37:44
UTC+2:

just technically speaking:
if your server stands in a DMZ, it has a internal LAN
side and an external WAN side.
You should be able to access the server (and an
application running on it) from the internal LAN side.
Then, why do you need an extra WLAN access point at the
server/ VM ?
I'm not saying that's not possible, but is it necessary ?

On 22.06.2023 20:05, metalmi...@gmail.com wrote:

Regarding your first post:

This is actually correct. I thought, the community here
in the google group may be larger and therefore I can
get more input.

I'm just wondering, if the Vantage Vue really is the
only weather station in this price range, which is
compatible with weewx.


"if you can access your VM via your local network, weewx
can access/can be accessed (depending on the consoles)
your console via the local network"

That is true, when the console and the vm are in the
same network, which is actually not the case. My server
is in a dmz and I only have wifi for my LAN, so USB
would be the easiest thing. Of course I can put a wifi
dongle to my server, pass it through to the vm and
connect the console of the weather station with that
wifi dongle, but that would be much more work.



Regarding your second post:


Of course it's a non-representative opinion about
Ecowitt/Froggit, but it's based on my experience and on
the experience of my friend. And in my opinion it's

Re: [weewx-user] Rain cumulative total wrong total in graph

2023-06-28 Thread Rainer Lang

It can be omitted (under normal circumstances)
I was/am using it because I combine/d different observations from
different weewx databases

with different rain gauges into one graph/picture.
I think the image generator needs to be told from where to take the data
if more than one
observation is under the e.g. [[[dayrainx]]] stanza in several
stanzas taking data from different databases

(plus it increases the readability of the code )

On 28.06.2023 01:22, Greg Reive wrote:

I don't think you need that line. Just comment it out.
I was playing with lots of options and forgot to remove that line.

On Wed, 28 Jun 2023 at 09:16, DR wrote:

I'm trying to learn how to do a fwe things, but am confused by the
need
for the data_binding statement:

> data_binding = wx_binding

Isn't this a default linkage, and for those of us with simple
databases
and setups, not needed? Just trying to cipher this out.

Thanks for any explanation. Dale

--
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/Td-2dHCXwaA/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/3684743c-e491-5297-5e7c-37b2d49a6729%40gmail.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/CAD_tbc8b5E47XCULGH9%2BLnaT%3DgC%3DJca26k-JptVA0sTrJf_Gng%40mail.gmail.com
.

Re: [weewx-user] Re: GW1000 Gateway - sensor battery stats not entering onto DB

2023-06-28 Thread Rainer Lang

"Where is this data actually stored if not in the database? Is there any 
way to test this out, besides actually using the said driver?"


The data is not stored on a medium (e.g. disk) but just kept in memory 
during the runtime of the program - and even there

only as long as the program logic allows.

Maybe the use of other terms will make it clearer if you are not 
familiar with the Python programming language and its jargon.
A dictionary in Python is a defined (potentially complex) data structure 
of the same or different data types.
These structures have different names in different programming 
languages. They exist during the runtime of the program and are used
to store data during runtime and also use this data during runtime. In 
older programming languages like COBOL they were just a so-called
record, a structured description of a memory area  (like a line in a 
spreadsheet with different columns).
On a low level they are (from the point of view of the computer program 
structured)

areas in memory which can be accessed and manipulated by the program code.

If you want to do testing here, whatever are your ideas here and 
whatever you want to do and for what purpose, you would have to create your

own Python code which does what you want to do (your "testing").
If you want to see the definition of these structures (Python dictionaries),
you will have to find the place where they are defined in the weewx coding.
As Python is an interpreter language, the program code is available on 
your computer.


I'm not exactly clear on what you want to "test" here and what for ...
- certain observations are stored or not stored, depending on what you 
want and define (e.g. in weewx.conf)
you want some observation to be stored, do it via the one of the two 
approaches mentioned earlier,
some are predefined by the database schema used, for others this would 
need to be defined
- you can also define what type of accumulation of this data you want 
(also in weewx.conf)
- when displaying the data you can also define (in skin.conf) what type 
of depiction your want


so much for the technical aspect - storing or not storing (storing here 
in the sense of archiving into a database)


as for the functional/logical aspect, you have to be clear on what the 
information you want to archive means
like in the example of the Ecowitt sensor "signal" observation which is 
an indicator of successfully received and processed data packages
i.e. rather a signal quality indicator but not a signal strength 
indicator. Even though on an Ecowitt console or app you can see 
"reception bars",
they cannot be compared to the signal reception bars of your mobile 
phone (where they are an indicator of signal strength).


If you want to enter more deeply into how Ecowitt consoles and sensors 
work, I recommend to read the (whole !) wxforum.net thread

https://www.wxforum.net/index.php?topic=40730.0
In the field of battery and signal values there is unfortunately 
(historically grown) not a consistent logic, especially with the batteries.

You have to know which values each sensor provides and what they mean

weewx is only using the output from these consoles through whichever 
driver you are using to do so (Ecowitt Gateway, Interceptor, RTL433).
It's up to you to make sense of it and what you choose to depict and how 
to depict.





On 28.06.2023 01:19, David Bätge wrote:

Hi Rainer and Gary,

thank you both very much for the detailed explanation! I was not aware 
that the $current tag also provides access to ALL observations of the 
current record, regardless if they are archived or not.


Is the $current tag the only tag that provides this access? I assume 
the $latest tag also does?


The $span tag would not be able to get values from those fields, since 
it's an aggregate, right? Just asking because I have added a check for 
displaying the battery states, like eg. #if 
$getattr($span($day_delta=1, boundary='midnight'), 
'wh31_ch1_batt').has_data which does not really make sense after 
understanding the internals, it should test against $current.


/[...] weewx includes values from the database and the current values 
of all observations in the current values table, also from those which 
have not been archived but are still available in *memory* from what 
has been provided from the driver [...]/
Where is this data actually stored if not in the database? Is there 
any way to test this out, besides actually using the said driver?


Sorry for a load of questions, please point me to the right 
documentation if I missed something in the guides. Thanks in advance 
and thanks again for enlighten me about this :)

gjr80 schrieb am Dienstag, 27. Juni 2023 um 18:21:54 UTC+2:

David,

Some answers/comments below.

On Tuesday, 27 June 2023 at 01:16:51 UTC+1 david@gmail.com wrote:


Signal level observations: All *_sig observations like,
wh31_ch1_sig, wh31_ch2_sig, wh32_sig. I don't understand
these: What

Re: [weewx-user] Re: GW1000 Gateway - sensor battery stats not entering onto DB

2023-06-27 Thread Rainer Lang


Hi David,
the sentence *"**/It is not necessary to do so if only displaying 
current values (ie values from the current archive record)"/*  is maybe 
a bit trickily phrased - at the time the report is generated weewx 
includes values from the database and the current values of all 
observations in the current values table, also from those which have not 
been archived but are still available in memory from what has been 
provided from the driver (here Ecowitt Gateway). That's what you address 
by $current.
They will be discarded/replaced by new values coming in - and won't be 
accessible later unless also archived by one of the methods described 
(new columns/fields or repurposing of existing schema fields) while the 
archived values are of course still accessible in the database.


On 27.06.2023 02:16, David Bätge wrote:

Hi Gary and Jon,

I just got some time to look into this (and also made some notes for 
myself):


First of all, the GW1000 driver provides a lot of sensor information, 
the complete list is:


_Batteries_:
wh31_ch1_batt
wh31_ch2_batt
wh32_batt
wh40_batt
wh41_ch1_batt
wh51_ch1_batt
wh57_batt
ws80_batt
ws90_batt

_Signals_:
wh31_ch1_sig
wh31_ch2_sig
wh32_sig
wh40_sig
wh41_ch1_sig
wh51_ch1_sig
wh57_sig
ws80_sig
ws90_sig


Here is the complete LOOP package with relevant values:
{
   'wh31_ch1_batt': '0',
   'wh31_ch1_sig': '4',
   'wh31_ch2_batt': '0',
   'wh31_ch2_sig': '4',
   'wh32_batt': '0',
   'wh32_sig': '4',
   'wh40_batt': '1.39',
   'wh40_sig': '4',
   'wh41_ch1_batt': '5',
   'wh41_ch1_sig': '4',
   'wh51_ch1_batt': '1.3',
   'wh51_ch1_sig': '4',
   'wh57_batt': '4',
   'wh57_sig': '4',
   'ws80_batt': 'None',
   'ws80_sig': '0',
   'ws90_batt': '2.86',
   'ws90_sig': '4',
}

To be honest, I don't quite understand all of the fields, but I will 
try to give an explanation and how to configure these fields in weewx-wdc:


Observations that show something like "Battery OK" or "Battery LOW" 
(where 0 is OK and 1 is LOW): `wh31_ch1_batt, wh31_ch2_batt, 
wh32_batt`, and `wh41_ch1_batt, wh57_batt` (see 
https://github.com/gjr80/weewx-gw1000/wiki/Sensor-battery-states). 
This kind of observation needs to be added to 
[DisplayOptions]sensor_battery_status in skin.conf.


*Note to me:* wh41_ch1_batt, wh57_batt using another representation of 
Battery status, see 
https://github.com/gjr80/weewx-gw1000/blob/master/supplementary/skins/Seasons/sensors.inc 
and 
https://github.com/gjr80/weewx-gw1000/wiki/Adapting-the-Seasons-skin-to-display-battery-states 
(There are a few tweaks needed to support these fields)


Signal level observations: All *_sig observations like, wh31_ch1_sig, 
wh31_ch2_sig, wh32_sig. I don't understand these: What is the signal 
level here? Values seem to be `0` or `4` in that LOOP packet (looks 
like battery state fields?).


Battery Voltages observations: wh40_batt, wh51_ch1_batt, ws80_batt, 
ws90_batt. These should be added to any of 
[DisplayOptions]sensor_stat_tile_observations, 
[DisplayOptions]sensor_diagram_observations or 
[DisplayOptions]sensor_table_observations in skin.conf.


So the problem with all these observations is basically (as far as I 
understand, please correct me if I am wrong): WeeWX does not know 
about them and does not save them to the database (but you will need 
this data to show plots of the battery voltages for the last week for 
example). There should be two ways to overcome this:


1. Add the fields provided by the GW1000 driver to the database, see 
http://weewx.com/docs/latest/customizing.htm#Modifying_an_existing_database
2. Map the GW1000 fields to WeeWX schema fields (see 
https://github.com/weewx/weewx/blob/master/bin/schemas/wview_extended.py#L16) 
I assume that was somehow done for a short period of time because e.g. 
rxCheckPercent or consBaterryVoltage are showing/having data for a few 
days!?)


@Gary I don't quite understand what you have written about that:

/It is not necessary to do so if only displaying current values (ie 
values from the current archive record)/


How would you show fields like wh41_ch1_batt from the current archive 
record when the data is not saved? Am I missing something?

gjr80 schrieb am Dienstag, 6. Juni 2023 um 13:32:47 UTC+2:

Jon,

No problems. The console output shows the Ecowitt gateway driver
is populating loop packets with sensor status data, eg ws90_sig,
wh57_batt etc. I assume the sensor data is complete for all
sensors registered with your gateway device (I cannot tell this,
only you can). WeeWX is then accumulating this data and it appears
in WeeWX generated archive records.

Looking at the weewx-wdc GitHub page it appears to use a similar
system to the Seasons skins for displaying sensor status data. The
default fields to be displayed are set in sensor-status.html.tmpl
and these can be overridden in skin.conf. The default appears to
include fields such as rxCheckPercent, consBatteryVoltage,
inTempBatteryStatus, rainBatteryStatus etc.

[weewx-user] Rain cumulative total wrong total in graph

2023-06-24 Thread Rainer Lang

 Forwarded Message 
Subject:Re: [weewx-user] Rain cumulative total wrong total in graph
Date:   Sat, 24 Jun 2023 14:42:09 +0200
From:   Rainer Lang 
To: weewx-user@googlegroups.com

the below works for me ...
    [[[yearrain1]]]
    # Make sure the y-axis increment is at least 0.02 for the 
rain plot

    yscale = None, None, 0.02
    plot_type = bar
    width = 1
    rain1
    fill_color = "#ff4500"  #red
 data_binding = wx_binding
 data_type = rain
    aggregate_type = cumulative
    label = text

On 24.06.2023 08:42, Greg Reive wrote:

I just want the cumulative total for the year to date.
It seems to work for day, week, month.

On Sat, 24 June 2023, 16:40 Graham Eddy,  wrote:

i just assumed you were comparing aggregation of 12 months with
aggregation since start of rainyear
*⊣GE⊢*

On 24 Jun 2023, at 3:52 pm, Greg from Oz  wrote:

I put this part in:
              rain_year_start = 1
But still not correct.

On Saturday, 24 June 2023 at 15:03:26 UTC+10 Greg Reive wrote:

What do you mean rain year date?

On Sat, 24 June 2023, 14:50 Graham Eddy,  wrote:

rainyear date?
*⊣GE⊢*

On 24 Jun 2023, at 2:27 pm, Greg from Oz
 wrote:

I have made a graph to show the cumulative rainfall and
it seems to show the correct values on the graphs for
day, week and month. They tally up with the figures that
weewx has calculated but the year total is way out and
the graph numbers are way out as well.
I cannot see why it would be so different.

I am using weewx version 4.10.2 and mysql

Here is the year configuration I am using which is
similar to the day, week and month.

[[[yearraincumulation]]]
           rain1
              data_binding = wx_binding
              data_type = rain
              aggregate_type = cumulative
              aggregate_interval = 604800 #1 day
              label = Rain cumulative
              plot_type = line
              line_type = solid
              line_gap_fraction = 0.5
It generates the graph:

The total weewx tells me for the year is:
478.8 mm
which is nowhere near the 1200 on the graph.
Very strange the other graphs work.

Here is my web page:
https://weather.ubeaut.work/year.html

Any ideas?
Thanks

-- 
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/97c7b8b9-d177-465a-b258-692a1e06226dn%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/97c7b8b9-d177-465a-b258-692a1e06226dn%40googlegroups.com?utm_medium=email_source=footer>.

-- 

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/Td-2dHCXwaA/unsubscribe.
To unsubscribe from this group and all its topics, send
an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/35952BFA-6255-4349-88DD-E1BB7B954697%40geddy.au

<https://groups.google.com/d/msgid/weewx-user/35952BFA-6255-4349-88DD-E1BB7B954697%40geddy.au?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/4665860b-848b-4ac9-8231-b266de44581fn%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/4665860b-848b-4ac9-8231-b266de44581fn%40googlegroups.com?utm_medium=email_source=footer>.

-- 
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/Td-2dHCXwaA/unsubscribe.
To unsubscribe from this group and all its topics, send

Re: [weewx-user] Rain cumulative total wrong total in graph

2023-06-24 Thread Rainer Lang

the below works for me ...
[[[yearrain1]]]
# Make sure the y-axis increment is at least 0.02 for the
rain plot

yscale = None, None, 0.02
plot_type = bar
width = 1
rain1
fill_color = "#ff4500" #red
data_binding = wx_binding
data_type = rain
aggregate_type = cumulative
label = text

On 24.06.2023 08:42, Greg Reive wrote:

I just want the cumulative total for the year to date.
It seems to work for day, week, month.

On Sat, 24 June 2023, 16:40 Graham Eddy, wrote:

i just assumed you were comparing aggregation of 12 months with
aggregation since start of rainyear
*⊣GE⊢*

On 24 Jun 2023, at 3:52 pm, Greg from Oz wrote:

I put this part in:
rain_year_start = 1
But still not correct.

On Saturday, 24 June 2023 at 15:03:26 UTC+10 Greg Reive wrote:

What do you mean rain year date?

On Sat, 24 June 2023, 14:50 Graham Eddy, wrote:

rainyear date?
*⊣GE⊢*

On 24 Jun 2023, at 2:27 pm, Greg from Oz
wrote:

I have made a graph to show the cumulative rainfall and
it seems to show the correct values on the graphs for
day, week and month. They tally up with the figures that
weewx has calculated but the year total is way out and
the graph numbers are way out as well.
I cannot see why it would be so different.

I am using weewx version 4.10.2 and mysql

Here is the year configuration I am using which is
similar to the day, week and month.

[[[yearraincumulation]]]
rain1
data_binding = wx_binding
data_type = rain
aggregate_type = cumulative
aggregate_interval = 604800 #1 day
label = Rain cumulative
plot_type = line
line_type = solid
line_gap_fraction = 0.5
It generates the graph:

The total weewx tells me for the year is:
478.8 mm
which is nowhere near the 1200 on the graph.
Very strange the other graphs work.

Here is my web page:
https://weather.ubeaut.work/year.html

Any ideas?
Thanks

--
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/97c7b8b9-d177-465a-b258-692a1e06226dn%40googlegroups.com

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/Td-2dHCXwaA/unsubscribe.
To unsubscribe from this group and all its topics, send
an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/35952BFA-6255-4349-88DD-E1BB7B954697%40geddy.au

--
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/4665860b-848b-4ac9-8231-b266de44581fn%40googlegroups.com

--
You received this message because you are subscribed to a topic in

https://groups.google.com/d/msgid/weewx-user/E8B1FD15-0728-4F55-9756-9C86FAAD67AE%40geddy.au

Re: [weewx-user] adding mm to daily rainfall

2023-06-23 Thread Rainer Lang

only changing the weewx.conf entry in [StdConvert] will not suffice,
will not work !

You have to do the whole database migration !!
As described in Tom Keffer's reply to the topic (details in the link in
Tom'S mail)

On 23.06.2023 08:37, Δημήτρης Βήχος wrote:
changed in weewx.conf from US to METRICWX. weewx never starts. i ll
trying one more time.

Στις Παρασκευή 23 Ιουνίου 2023 στις 9:22:44 π.μ. UTC+3, ο χρήστης
Rainer Lang έγραψε:

what exactly did you do ?
migrated the (data from the) old database into a new database with
METRICWX as described in Tom's link in the customization guide ?
(by the way, the unit system nam is METRICWX and *NOT* METRIXCW -
could this be the reason for weewx not coming up ?)

Can you please set DEBUG=3 in weewx.conf, restart weewx and
provide the syslog data here
Some information will be there ...
On 23.06.2023 08:03, Δημήτρης Βήχος wrote:

changed from US default to METRIXCW weewx dont startup

Στις Πέμπτη 22 Ιουνίου 2023 στις 10:15:13 μ.μ. UTC+3, ο χρήστης
Tom Keffer έγραψε:

See the section /Changing the unit system in an existing
database

<https://weewx.com/docs/latest/customizing.htm#Changing_the_unit_system>/
in the Customization Guide.

On Wed, Jun 21, 2023 at 12:45 PM Δημήτρης Βήχος
wrote:

finaly i did it with sqlitebrowser easily! thank you!
is there way my data base appears values to mm and C for
temp, instead to inches and F ?

Στις Τετάρτη 21 Ιουνίου 2023 στις 4:17:58 μ.μ. UTC+3, ο
χρήστης Rainer Lang έγραψε:

At the end of the day it doesn't matter where the
weewx.sdb is located - as long as weewx and
wee_database via weewx.conf and sqlite3 via the path
in the command know/are told
where it is located.

You can still check with sqlitebrowser what your
entry in your database for the respective EPOCH
timestamp is (see my earlier mail) - and you can
change it manually
(provided you start it with sudo sqlitebrowser
/var/lib/weewx/weewx.sdb [in your case]).
That's the pragmatic approach.

Of course you can still try to figure out why your
SQL command doesn't seem to have been successful.

On 21.06.2023 13:24, Δημήτρης Βήχος wrote:

my database is on /var/lib/weewx/weewx.sdb

metfm@metfm:~$ ls -ail /var/lib/weewx
σύνολο 18692
264962 drwxr-xr-x 1 root root 18 Ιουν 21 14:20 .
269 drwxr-xr-x 1 root root 592 Φεβ 26 18:30 ..
270727 -rwxrwxrwx 1 root root 19140608 Ιουν 21 14:20
weewx.sdb
metfm@metfm:~$

Στις Τετάρτη 21 Ιουνίου 2023 στις 11:49:35 π.μ.
UTC+3, ο χρήστης gjr80 έγραψε:

No. The default Debian based distro database is
/var/lib/weewx/weewx.sdb. The archive directory
is only used (by default) for setup.py installs.

OP. Have you confirmed the location (and name)
of your WeeWX database? What does the following
command show:

$ ls -ail /var/lib/weewx

Gary

On Wednesday, 21 June 2023 at 09:28:58 UTC+1
stefanos...@gmail.com wrote:

It should be /var/lib/weewx/archive/weewx.sdb

Can you give us a screenshot where the
weewx.sdb is??

Στις Τετ, 21 Ιουν 2023, 11:03 ο χρήστης
Δημήτρης Βήχος έγραψε:

debian installed. also triyng with sudo
sqlite3 /var/lib/weewx/weewx.sdb same
thing.

Στις Τετάρτη 21 Ιουνίου 2023 στις
9:55:34 π.μ. UTC+3, ο χρήστης gjr80 έγραψε:

Have you customised your WeeWX
install? You appear to be using a
package install so unless you have
changed it your WeeWX database
should be in /var/lib/weewx not
/var/weewx.

Gary

On Wednesday, 21 June 2023 at
05:48:19 UTC+1 hobbyl...@gmail.com
wrote:

the commands with semi-colons.
send me (with sudo also and with
suo su )

Re: [weewx-user] adding mm to daily rainfall

2023-06-23 Thread Rainer Lang

what exactly did you do ?
migrated the (data from the) old database into a new database with
METRICWX as described in Tom's link in the customization guide ?
(by the way, the unit system nam is METRICWX and *NOT* METRIXCW - could
this be the reason for weewx not coming up ?)

Can you please set DEBUG=3 in weewx.conf, restart weewx and provide the
syslog data here

Some information will be there ...
On 23.06.2023 08:03, Δημήτρης Βήχος wrote:

changed from US default to METRIXCW weewx dont startup

Στις Πέμπτη 22 Ιουνίου 2023 στις 10:15:13 μ.μ. UTC+3, ο χρήστης Tom
Keffer έγραψε:

See the section /Changing the unit system in an existing database
<https://weewx.com/docs/latest/customizing.htm#Changing_the_unit_system>/
in the Customization Guide.

On Wed, Jun 21, 2023 at 12:45 PM Δημήτρης Βήχος
wrote:

finaly i did it with sqlitebrowser easily! thank you!
is there way my data base appears values to mm and C for temp,
instead to inches and F ?

Στις Τετάρτη 21 Ιουνίου 2023 στις 4:17:58 μ.μ. UTC+3, ο
χρήστης Rainer Lang έγραψε:

At the end of the day it doesn't matter where the
weewx.sdb is located - as long as weewx and wee_database
via weewx.conf and sqlite3 via the path in the command
know/are told
where it is located.

You can still check with sqlitebrowser what your entry in
your database for the respective EPOCH timestamp is (see
my earlier mail) - and you can change it manually
(provided you start it with sudo sqlitebrowser
/var/lib/weewx/weewx.sdb [in your case]).
That's the pragmatic approach.

Of course you can still try to figure out why your SQL
command doesn't seem to have been successful.

On 21.06.2023 13:24, Δημήτρης Βήχος wrote:

my database is on /var/lib/weewx/weewx.sdb

Στις Τετάρτη 21 Ιουνίου 2023 στις 11:49:35 π.μ. UTC+3, ο
χρήστης gjr80 έγραψε:

No. The default Debian based distro database is
/var/lib/weewx/weewx.sdb. The archive directory is
only used (by default) for setup.py installs.

OP. Have you confirmed the location (and name) of
your WeeWX database? What does the following command
show:

$ ls -ail /var/lib/weewx

Gary

On Wednesday, 21 June 2023 at 09:28:58 UTC+1
stefanos...@gmail.com wrote:

It should be /var/lib/weewx/archive/weewx.sdb

Can you give us a screenshot where the weewx.sdb is??

Στις Τετ, 21 Ιουν 2023, 11:03 ο χρήστης Δημήτρης
Βήχος έγραψε:

debian installed. also triyng with sudo
sqlite3 /var/lib/weewx/weewx.sdb same thing.

Στις Τετάρτη 21 Ιουνίου 2023 στις
9:55:34 π.μ. UTC+3, ο χρήστης gjr80 έγραψε:

Have you customised your WeeWX install?
You appear to be using a package install
so unless you have changed it your WeeWX
database should be in /var/lib/weewx not
/var/weewx.

Gary

On Wednesday, 21 June 2023 at 05:48:19
UTC+1 hobbyl...@gmail.com wrote:

the commands with semi-colons. send
me (with sudo also and with suo su )

metfm@metfm:~$ sudo sqlite3
/var/weewx/weewx.sdb
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> SELECT dateTime,
datetime(dateTime,
'unixepoch','localtime'), usUnits,
rain FROM archive WHERE dateTime >
1686881600 AND dateTime <= 1686981600;
Error: unable to open database
"/var/weewx/weewx.sdb": unable to
open database file
metfm@metfm:~$

without semi-colons database open

Re: [weewx-user] Re: weather station for 400-600 Euros

2023-06-22 Thread 'Rainer Lang' via weewx-user

and that's more than enough for the Ecowitt console(s) to post their 
data to weewx 
(apart from the possibility to introduce specific firewall rules on 
specific ports )


On 22.06.2023 20:52, metalmi...@gmail.com wrote:

Because the server is in a different subnet than my LAN.

Let's say the server is in the 10.10.20.0/24 net and on my LAN I have 
the 10.10.10.0/24 net. A demilitarized zone (DMZ) has only access to 
the internet and to no other net. A Firewall rule blocks outgoing 
connections from the DMZ to all other nets, exept the internet. So 
from the VM I have no access to my LAN, where the console would be. 
*The other way round is possible, from my LAN network I have full 
access to all machines and services in the DMZ. **

*
Rainer Lang schrieb am Donnerstag, 22. Juni 2023 um 20:37:44 UTC+2:

just technically speaking:
if your server stands in a DMZ, it has a internal LAN side and an
external WAN side.
You should be able to access the server (and an application
running on it) from the internal LAN side.
Then, why do you need an extra WLAN access point at the server/ VM ?
I'm not saying that's not possible, but is it necessary ?

On 22.06.2023 20:05, metalmi...@gmail.com wrote:

Regarding your first post:

This is actually correct. I thought, the community here in the
google group may be larger and therefore I can get more input.

I'm just wondering, if the Vantage Vue really is the only weather
station in this price range, which is compatible with weewx.


"if you can access your VM via your local network, weewx can
access/can be accessed (depending on the consoles) your console
via the local network"

That is true, when the console and the vm are in the same
network, which is actually not the case. My server is in a dmz
and I only have wifi for my LAN, so USB would be the easiest
thing. Of course I can put a wifi dongle to my server, pass it
through to the vm and connect the console of the weather station
with that wifi dongle, but that would be much more work.



Regarding your second post:


Of course it's a non-representative opinion about
Ecowitt/Froggit, but it's based on my experience and on the
experience of my friend. And in my opinion it's totally legit to
make future decisions from these experiences.

Ok, I have to admit, that I didn't know, that there is such a big
difference in these models.

I'm totally aware, that shit happens at Ecowitt and at Davis,
that's no question.

The reason why I thought, that the person who replied to my topic
works for Ecowitt is firstly, that he was totally focussed on
Ecowitt products and secondly that he wrote "have a look at the
overview in OUR wiki". This could lead to the assumption, that he
works for the company. Please get me right, I'm totally fine with
his answer. It's totally subject-related and super helpful.

Of course what I do here are "complaints at a high level", but
I'm just checking my options. As I said, not only my family sees
the data of the weather station, our whole village has access to
it. Therefore, I would like to provide a service which is as
reliable, as it can be (in a certain price range of course).


Right now, there is no choice, but the comparison with the cars
was very helpful.


Rainer Lang schrieb am Donnerstag, 22. Juni 2023 um 19:36:35 UTC+2:

sorry to say that but you are just trading subjective
non-representative opinions regarding Ecowitt (and clone)
stations and hardware

modern Ecowitt stations have proven to be quite reliable and
to compare an ancient WH1080 with the modern Fine Offset /
Ecowitt hardware is like comparing a year 2020 BMW or
Mercedes with the models around the year 1940.

Most of the Ecowitt station owners nowadays are quite happy
with their choice. Shit can always happen, also with a 2-5
times more expensive Davis Weather station. The main users of
the German Weather forum are quite critical regarding quality
etc. - and of course nothing is perfect (a Davis Vantage Pro2
neither). In that forum they call a spade a spade and nobody
has a business relation to FineOffset/Ecowitt there (what you
are insinuating in your mail). Some shortcomings of the
modern Ecowitt stations exist, yes, but are not in the area
of longevity so far. Mostly rather what Germans call
"complaints at a very high level".

But of course the choice is yours

On 22.06.2023 19:15, metalmi...@gmail.com wrote:

Thanks Michael for your reply.

I'm aware of the Ecowitt/Universe. Earlier this afternoon, a
guy from Ecowitt suggested some Froggit Stations, for
example the Froggit HP1000SE Pro Ultrasonic and the
GW2

Re: [weewx-user] Re: weather station for 400-600 Euros

2023-06-22 Thread 'Rainer Lang' via weewx-user


just technically speaking:
if your server stands in a DMZ, it has a internal LAN side and an 
external WAN side.
You should be able to access the server (and an application running on 
it) from the internal LAN side.

Then, why do you need an extra WLAN access point at the server/ VM ?
I'm not saying that's not possible, but is it necessary ?

On 22.06.2023 20:05, metalmi...@gmail.com wrote:

Regarding your first post:

This is actually correct. I thought, the community here in the google 
group may be larger and therefore I can get more input.


I'm just wondering, if the Vantage Vue really is the only weather 
station in this price range, which is compatible with weewx.



"if you can access your VM via your local network, weewx can 
access/can be accessed (depending on the consoles) your console via 
the local network"


That is true, when the console and the vm are in the same network, 
which is actually not the case. My server is in a dmz and I only have 
wifi for my LAN, so USB would be the easiest thing. Of course I can 
put a wifi dongle to my server, pass it through to the vm and connect 
the console of the weather station with that wifi dongle, but that 
would be much more work.




Regarding your second post:


Of course it's a non-representative opinion about Ecowitt/Froggit, but 
it's based on my experience and on the experience of my friend. And in 
my opinion it's totally legit to make future decisions from these 
experiences.


Ok, I have to admit, that I didn't know, that there is such a big 
difference in these models.


I'm totally aware, that shit happens at Ecowitt and at Davis, that's 
no question.


The reason why I thought, that the person who replied to my topic 
works for Ecowitt is firstly, that he was totally focussed on Ecowitt 
products and secondly that he wrote "have a look at the overview in 
OUR wiki". This could lead to the assumption, that he works for the 
company. Please get me right, I'm totally fine with his answer. It's 
totally subject-related and super helpful.


Of course what I do here are "complaints at a high level", but I'm 
just checking my options. As I said, not only my family sees the data 
of the weather station, our whole village has access to it. Therefore, 
I would like to provide a service which is as reliable, as it can be 
(in a certain price range of course).



Right now, there is no choice, but the comparison with the cars was 
very helpful.



Rainer Lang schrieb am Donnerstag, 22. Juni 2023 um 19:36:35 UTC+2:

sorry to say that but you are just trading subjective
non-representative opinions regarding Ecowitt (and clone) stations
and hardware

modern Ecowitt stations have proven to be quite reliable and to
compare an ancient WH1080 with the modern Fine Offset / Ecowitt
hardware is like comparing a year 2020 BMW or Mercedes with the
models around the year 1940.

Most of the Ecowitt station owners nowadays are quite happy with
their choice. Shit can always happen, also with a 2-5 times more
expensive Davis Weather station. The main users of the German
Weather forum are quite critical regarding quality etc. - and of
course nothing is perfect (a Davis Vantage Pro2 neither). In that
forum they call a spade a spade and nobody has a business relation
to FineOffset/Ecowitt there (what you are insinuating in your
mail). Some shortcomings of the modern Ecowitt stations exist,
yes, but are not in the area of longevity so far. Mostly rather
what Germans call "complaints at a very high level".

But of course the choice is yours

On 22.06.2023 19:15, metalmi...@gmail.com wrote:

Thanks Michael for your reply.

I'm aware of the Ecowitt/Universe. Earlier this afternoon, a guy
from Ecowitt suggested some Froggit Stations, for example
the Froggit HP1000SE Pro Ultrasonic and the GW2000/DP2000 in a
German forum for weather stations.

Since a friend of mine had also a WH1080 SE which died within 4
years and mine is also dying now, I'm not sure about the
reliability of the hardware from Ecowitt/Froggit. That's the
reason, I want to get more robust and stable hardware.


michael.k...@gmx.at schrieb am Donnerstag, 22. Juni 2023 um
19:05:14 UTC+2:

Hi Flo, I had similar requirements and finally bought Ecowitt
hardware some weeks ago and I'm really happy with it. They
have a modular approch and you can choose between numerous
consoles, gateways, sensors, ... That was the main reason why
I chose this hardware. You can also get spare parts and extra
sensors any time later.

There is also a significant large community running this type
of hardware.

All sensors come with independent wireless transmission, but
there is no USB connection for the data transfer. But, if you
buy the gateway, with the GW1000 driver it should b

Re: [weewx-user] Re: weather station for 400-600 Euros

2023-06-22 Thread 'Rainer Lang' via weewx-user

sorry to say that but you are just trading subjective non-representative
opinions regarding Ecowitt (and clone) stations and hardware

modern Ecowitt stations have proven to be quite reliable and to compare
an ancient WH1080 with the modern Fine Offset / Ecowitt hardware is like
comparing a year 2020 BMW or Mercedes with the models around the year 1940.

Most of the Ecowitt station owners nowadays are quite happy with their
choice. Shit can always happen, also with a 2-5 times more expensive
Davis Weather station. The main users of the German Weather forum are
quite critical regarding quality etc. - and of course nothing is perfect
(a Davis Vantage Pro2 neither). In that forum they call a spade a spade
and nobody has a business relation to FineOffset/Ecowitt there (what you
are insinuating in your mail). Some shortcomings of the modern Ecowitt
stations exist, yes, but are not in the area of longevity so far. Mostly
rather what Germans call "complaints at a very high level".

But of course the choice is yours

On 22.06.2023 19:15, metalmi...@gmail.com wrote:

Thanks Michael for your reply.

I'm aware of the Ecowitt/Universe. Earlier this afternoon, a guy from
Ecowitt suggested some Froggit Stations, for example the Froggit
HP1000SE Pro Ultrasonic and the GW2000/DP2000 in a German forum for
weather stations.

Since a friend of mine had also a WH1080 SE which died within 4 years
and mine is also dying now, I'm not sure about the reliability of the
hardware from Ecowitt/Froggit. That's the reason, I want to get more
robust and stable hardware.

michael.k...@gmx.at schrieb am Donnerstag, 22. Juni 2023 um 19:05:14
UTC+2:

Hi Flo, I had similar requirements and finally bought Ecowitt
hardware some weeks ago and I'm really happy with it. They have a
modular approch and you can choose between numerous consoles,
gateways, sensors, ... That was the main reason why I chose this
hardware. You can also get spare parts and extra sensors any time
later.

There is also a significant large community running this type of
hardware.

All sensors come with independent wireless transmission, but there
is no USB connection for the data transfer. But, if you buy the
gateway, with the GW1000 driver it should be even more easy to get
the data into weewx running in a VM using (W)LAN.

I spent not even 500€ for:

- wireless HumiTemp Outdoor Sensor
- a nice, customisable console, wall mountable, SD-Card data storage
- indoor humitemp & pressure sensor
- the gateway
- a lightning sensor
- a 7-in-1 sensor with an ultrasonic anemometer, luminosity
sensor, piezo rain sensor, extra outside humitemp sensor
(overruled by the other sensor)
- a classic rain gauge with bucket

There are more sensors available you can connect, like for air
quality, leaf wetness, soil temperature, extra humitemp sensors,

In EU (DE) there is froggit branded ecowitt hardware available.
https://www.froggit.de/

Or buy from ecowitt directly, they should take care of all tax and
customs fees: https://shop.ecowitt.com/

metalmi...@gmail.com schrieb am Donnerstag, 22. Juni 2023 um
17:31:53 UTC+2:

Hi guys,

as the title suggest, I'm searching for a weather station in
the 400-600 Euro price range. Currently I have a Froggit
WH1080 SE, but after around 4.5 years, it seems that the
station could fail completely in the next days/weeks. So I'd
like to be prepared, if it's completely broken.

What I would like to have with the new station:

- More robust and longer lasting hardware
- Console with a nice big display
- Wall mountable console
- Wireless data transmission
- USB connection from the console to the pc preferred, since
weewx runs in a virtual machine on my server (if everything
else fits, the usb connection is not crucial, I can find a
solution)

I had a look at the Davis Vantage Vue, but the 250 Euro extra
for the usb adapter hurt.

So if you have any alternative, feel free to comment. ;)

Thank you for your help!

Flo

Re: [weewx-user] weather station for 400-600 Euros

2023-06-22 Thread 'Rainer Lang' via weewx-user

it seems you posted the same question in the German Weather Forum 
https://wetterstationsforum.info
There you already got the suggestion to read their WiKi section about 
Ecowitt (clone) weather stations:

https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen
and the central wxforum.net thread in the Ambient/FineOffset/Ecowitt forum
https://www.wxforum.net/index.php?topic=40730.0

as far as pricing is concerned, look up https://www.froggit.com or 
https://shop.ecowitt.com or the Ecowitt Store at amazon.de


the different Ecowitt stations all fulfill you mentioned needs - up to 
you to choose/select one based on criteria like

- extra sensors beyond basic wind, rain, outdoor T/RH, solar radiation, UVI
- expandability

or compose something yourself

depending on your choice you will end up between 250 - 400 EUR.

the "need" for USB for weewx running in a VM is not a real need - unless 
you have a completely closed down VM from the network point of view - 
what nobody normally does

(even a Secure Cell has network access via restricted firewall rules)
if you can access your VM via your local network, weewx can access/can 
be accessed (depending on the consoles) your console via the local network


with Ecowitt stations you can get a host of different sensors (if wanted 
or needed) beyond the very basic stuff at a reasonable price/performance 
ratio.


On 22.06.2023 17:31, metalmi...@gmail.com wrote:

Hi guys,

as the title suggest, I'm searching for a weather station in the 
400-600 Euro price range. Currently I have a Froggit WH1080 SE, but 
after around 4.5 years, it seems that the station could fail 
completely in the next days/weeks. So I'd like to be prepared, if it's 
completely broken.


What I would like to have with the new station:

- More robust and longer lasting hardware
- Console with a nice big display
- Wall mountable console
- Wireless data transmission
- USB connection from the console to the pc preferred, since weewx 
runs in a virtual machine on my server (if everything else fits, the 
usb connection is not crucial, I can find a solution)


I had a look at the Davis Vantage Vue, but the 250 Euro extra for the 
usb adapter hurt.


So if you have any alternative, feel free to comment. ;)


Thank you for your help!

Flo
--
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/4eaf4bd0-85f3-4d0e-b83f-65877306815bn%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/e679db75-206a-cd0f-f89d-93141d027494%40gmail.com.

Re: [weewx-user] Plot for progressive rain accumulation

2023-06-22 Thread Rainer Lang


something like this should work:
(you need to put your own labels )

   [[[dayrain4]]]
    # Make sure the y-axis increment is at least 0.02 for the 
rain plot

    yscale = None, None, 0.02
    plot_type = bar   #line
    width = 2

    rain1  #WH40 rain
  data_binding = wx_binding
  data_type = rain
    aggregate_type = cumulative
    aggregate_interval = 300
    label = Rain WH40

On 22.06.2023 14:42, DR wrote:
I have looked through again the Customization guide, the Image Files 
section and don't find a pre-programmed option for a plot which I'd 
like to have.


There are a lot, but when it comes to rain, the hour  by hour plot 
shows when and how much, but I'm hoping to find a plot that shows the 
more (to me) traditional graphing of rain, starting at zero and then 
as rain came in, a steadily increasing line which would show total to 
that time, but also the slope of the line would indicate the rate.  As 
the rain stopped, the line would level off and continue on until more 
rain started, then continue to increase.  Most of my experience is 
with these types of  graphs and sort of like knowing how to read an 
analogue watch vs. digital, the data are there, but what  you grew up 
with is more instinctive for me at least.



During the Belchertown discussion on lightning, I think there was a 
background chart with that type of progressive rain display showing.



Is there a plot that I can put into my Seasons skin to allow this 
plot, or is the only one available the one shown, where the bar graph 
shown is the only one available?



Thanks.  Dale




--
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/46fba722-ad5b-092f-1f87-e5cf67e8fc53%40gmail.com.

[weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [3]

2023-06-21 Thread 'Rainer Lang' via weewx-user

Hi Gary,

I think you know that by saying that your driver were "dump" I didn't
want to discredit your work.  - Just that the work is done by the
console (or earlier in the chain).

The WH57 provides only the number of strikes since the last reporting
including the distance of that last strike. In an interval of 79 seconds
which starts with the first detection.
It's the console which does the counting and adds the EPOCH time stamp
as the WH57 has no internal clock which is gauged against current real time.
From there the API response from the console is number of strikes, time
stamp of last strike, distance of last strike (which will be saved in
the console after a thunderstorm until the next lightning detection).
The number of strikes (strike count) is reset to zero by the console at
midnight. That's why it keeps on sending, count 0, distance last strike,
time stamp last strike after a day with lightnings and no new lightning
detected past midnight.
The detection, counting etc. is done by the AS3935 IC inside the WH57
(https://www.sciosense.com/products/wireless-sensor-nodes/as3935-franklin-lightning-sensor-ic/

As for weighting, I don't see a reason for that either.

Rainer

On 21.06.2023 22:32, gjr80 wrote:
I really don't see the point of trying to weight lightning strike
distance from a WH57. In essence the WH57 reports three things; the
number of lightning strike detected today, the time of the last
detected lightning strike and the distance of the last lightning
strike. This is clearly stated in the WH57 manual. The Ecowitt Gateway
API is not so specific (it omits the word 'last'), but the API reports
the same data as displayed by the Ecowitt's WSView Plus app so I think
it is safe to assume the API reports time and distance of last strike.
So if a given number of lightning strikes occur in a period the
Ecowitt gateway driver and any connected console/app will only see
time and distance data for the last detected strike, nothing for any
earlier strikes.

The referenced PR does not state what type of lighting detector is
used, but the code looks suspiciously Ecowitt gateway driver'ish and
for the reasons outlined above I really don't see any value in
weighting light strike distance.

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/bcd2d06b-bfb6-48bd-b290-d8710a869ddan%40googlegroups.com
.

[weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [2]

2023-06-21 Thread 'Rainer Lang' via weewx-user


Google is your friend (most of the time  )

read https://www.wxforum.net/index.php?topic=40093.msg460073#msg460073

It's generally good to look for answers regarding Fine Offset/Ecowitt 
(clone) hardware in the wxforum 
https://www.wxforum.net/index.php?board=111.0
(and for German speaking people - gmx.at looks like Austria - also in 
https://www.wetterstationsforum.info/index.php and their related WiKi 
for Ecowitt stations) 


On 21.06.2023 21:48, Rainer Lang wrote:


That's rather a question for the wxforum 
https://www.wxforum.net/index.php?board=111.0

it's not really a weewx question

In a way the Ecowitt gateway driver is dumb - it just asks the console 
(GW1x00, GW2000, WH2650, WN19x0) for information, receives it and puts 
it into the weewx loop.
Depending on some settings in weewx.conf, weewx does some own 
calculation but nothing regarding the WH57.


If you want to know what the driver receives in detail, look up 
https://www.wxforum.net/index.php?topic=40730.0

and read the section about the Ecowitt Gateway driver.

Basically, in a nutshell, the WH57 itself already provides all this 
info to the console - the console just records it and hands it over to 
the weewx Ecowitt Gateway driver on request.


On 21.06.2023 21:37, michael.k...@gmx.at wrote:

How are lightning strikes and lightning distance calculated?

- How does the WH57 do it?
- How does the Ecowitt Gateway Driver do it?

Lightning distance and lightning strike count aren't independent 
values when you don't look at the events individually, but over a 
observation period:


- WH57 has an Interval of 79 seconds. Within 79 seconds many 
lightning events can occur. When the Sensors emits a new value, is 
the distance weighted? If not, any further calculations are pointless 
anyway. (Maybe Rainer Lang knows the answer or knows someone who 
knows the answer)
- weewx has an archive_interval, does the driver weight the 
distance/count or is the value for the interval just the average of 
the individual distance values?


For the basic topic see also https://github.com/weewx/weewx/pull/734
--
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/9aa91a43-55e5-4065-9039-529d33464609n%40googlegroups.com 
<https://groups.google.com/d/msgid/weewx-user/9aa91a43-55e5-4065-9039-529d33464609n%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/eb351706-e99b-6f91-2ddf-c2b960181a15%40gmail.com.

Re: [weewx-user] adding mm to daily rainfall

2023-06-21 Thread 'Rainer Lang' via weewx-user

afaik only if from the very beginning you choose this unit system - once
started you cannot change this anymore
(or at least not easily - in principle you could make a migration, but
in my estimate this would require quite some effort)

On 21.06.2023 21:45, Δημήτρης Βήχος wrote:

finaly i did it with sqlitebrowser easily! thank you!
*is there way my data base appears values to mm and C for temp,
instead to inches and F ? *

Στις Τετάρτη 21 Ιουνίου 2023 στις 4:17:58 μ.μ. UTC+3, ο χρήστης Rainer
Lang έγραψε:

At the end of the day it doesn't matter where the weewx.sdb is
located - as long as weewx and wee_database via weewx.conf and
sqlite3 via the path in the command know/are told
where it is located.

You can still check with sqlitebrowser what your entry in your
database for the respective EPOCH timestamp is (see my earlier
mail) - and you can change it manually
(provided you start it with sudo sqlitebrowser
/var/lib/weewx/weewx.sdb [in your case]).
That's the pragmatic approach.

Of course you can still try to figure out why your SQL command
doesn't seem to have been successful.

On 21.06.2023 13:24, Δημήτρης Βήχος wrote:

my database is on /var/lib/weewx/weewx.sdb

Στις Τετάρτη 21 Ιουνίου 2023 στις 11:49:35 π.μ. UTC+3, ο χρήστης
gjr80 έγραψε:

No. The default Debian based distro database is
/var/lib/weewx/weewx.sdb. The archive directory is only used
(by default) for setup.py installs.

OP. Have you confirmed the location (and name) of your WeeWX
database? What does the following command show:

$ ls -ail /var/lib/weewx

Gary

On Wednesday, 21 June 2023 at 09:28:58 UTC+1
stefanos...@gmail.com wrote:

It should be /var/lib/weewx/archive/weewx.sdb

Can you give us a screenshot where the weewx.sdb is??

Στις Τετ, 21 Ιουν 2023, 11:03 ο χρήστης Δημήτρης Βήχος
έγραψε:

debian installed. also triyng with sudo sqlite3
/var/lib/weewx/weewx.sdb same thing.

Στις Τετάρτη 21 Ιουνίου 2023 στις 9:55:34 π.μ. UTC+3,
ο χρήστης gjr80 έγραψε:

Have you customised your WeeWX install? You
appear to be using a package install so unless
you have changed it your WeeWX database should be
in /var/lib/weewx not /var/weewx.

Gary

On Wednesday, 21 June 2023 at 05:48:19 UTC+1
hobbyl...@gmail.com wrote:

the commands with semi-colons. send me (with
sudo also and with suo su )

metfm@metfm:~$ sudo sqlite3 /var/weewx/weewx.sdb
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> SELECT dateTime, datetime(dateTime,
'unixepoch','localtime'), usUnits, rain FROM
archive WHERE dateTime > 1686881600 AND
dateTime <= 1686981600;
Error: unable to open database
"/var/weewx/weewx.sdb": unable to open
database file
metfm@metfm:~$

without semi-colons database open

metfm@metfm:~$ sudo sqlite3 /var/weewx/weewx.sdb
[sudo] password for metfm:
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> select datetime, datetime(dateTime,
'unixepoch','localtime'), rain from archive
where dateTime > 1686881600 and dateTime <=
1686981600
...> update archive set rain=12.6 where
dateTime = 1686975900
...> .quit
...>
metfm@metfm:~$ sudo wee_database
--rebuild-daily --from=2023-06-17 --to=2023-06-17
[sudo] password for metfm:
Using configuration file /etc/weewx/weewx.conf
Using database binding 'wx_binding', which is
bound to database 'archive_sqlite'
Daily summary for 2023-06-17 will be rebuilt.
Proceed (y/n)? y
Rebuilding daily summaries in database

Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data

2023-06-21 Thread 'Rainer Lang' via weewx-user

That's rather a question for the wxforum
https://www.wxforum.net/index.php?board=111.0

it's not really a weewx question

In a way the Ecowitt gateway driver is dumb - it just asks the console
(GW1x00, GW2000, WH2650, WN19x0) for information, receives it and puts
it into the weewx loop.
Depending on some settings in weewx.conf, weewx does some own
calculation but nothing regarding the WH57.

If you want to know what the driver receives in detail, look up
https://www.wxforum.net/index.php?topic=40730.0

and read the section about the Ecowitt Gateway driver.

Basically, in a nutshell, the WH57 itself already provides all this info
to the console - the console just records it and hands it over to the
weewx Ecowitt Gateway driver on request.

On 21.06.2023 21:37, michael.k...@gmx.at wrote:

How are lightning strikes and lightning distance calculated?

- How does the WH57 do it?
- How does the Ecowitt Gateway Driver do it?

Lightning distance and lightning strike count aren't independent
values when you don't look at the events individually, but over a
observation period:

- WH57 has an Interval of 79 seconds. Within 79 seconds many lightning
events can occur. When the Sensors emits a new value, is the distance
weighted? If not, any further calculations are pointless anyway.
(Maybe Rainer Lang knows the answer or knows someone who knows the answer)
- weewx has an archive_interval, does the driver weight the
distance/count or is the value for the interval just the average of
the individual distance values?

For the basic topic see also https://github.com/weewx/weewx/pull/734
--
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/9aa91a43-55e5-4065-9039-529d33464609n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/9aa91a43-55e5-4065-9039-529d33464609n%40googlegroups.com?utm_medium=email_source=footer>.

Re: [weewx-user] Re: WS90 Signal Strength And Battery Status

2023-06-21 Thread 'Rainer Lang' via weewx-user

what the driver reads from the console and what is stored in the 
database are two completely different things.
You can display in the Seasons skin all these values as current values 
as long as they are used by index.html.tmpl and its inclusion files 
(*.inc).'
But stored in the database is only for what a respective standard field 
exists in the ws_extended database schema.
And everything else but the current values is displayed only when there 
is a corresponding (and addressed !) field in the database.

You better read my earlier mail closely ...

What you want can be done, but it's a bigger piece of work and also 
depends on what way of implementation you choose (database extension or 
repurposing).
And I'm not sure if someone here in the community is ready to do all 
this work for you. It's not just 2-3 lines and done.


You need to have some Linux and Python knowledge - and understand how 
weewx works - before you can make changes.


There are "readimade" weewx.conf, skin.conf etc. files available created 
by some enthousiastic developer which would meet your needs (covering 
all possible Ecowitt sensors and data which the Ecowitt Gateway driver 
reads including database extension etc.), but without a deeper 
understanding of how weewx works there is no point in throwing them 
"over the fence" *)


so "SKILL SET is low" is unfortunately not a good start, unless, as said 
earlier, someone is willing to do this job for you


*) if you still feel keen to work with them (including your contribution 
in getting more knowledgeable), send me a PM


On 21.06.2023 20:54, weewx-user wrote:
I have used the Ecowit Gateway Driver from here - 
https://github.com/gjr80/weewx-gw1000 and read the Wiki from here 
https://github.com/gjr80/weewx-gw1000/wiki and followed the steps as 
best I can (see my comments about my skin set before)


If I use PYTHONPATH=/usr/share/weewx python -m user.gw1000 
--test-driver the following is returned


Using configuration file /etc/weewx/weewx.conf

Interrogating GW2000 at 192.168.1.45:45000

2023-06-21 19:52:36 BST (1687373556): 'co2': '400', 'co2_24h_avg': 
'404', 'dateTime': '1687373556', 'daymaxwind': '5.8', 'dayRain': 
'0.0', 'extraHumid1': '48', 'extraHumid2': '36', 'extraHumid3': '41', 
'extraHumid17': '58', 'extraTemp1': '26.4', 'extraTemp2': '33.4', 
'extraTemp3': '28.0', 'extraTemp17': '24.8', 'inHumidity': '54', 
'inTemp': '23.9', 'lightning_distance': '37', 
'lightning_last_det_time': '1687271411', 'lightning_strike_count': 
'None', 'lightningcount': '0', 'luminosity': '7120.0', 'monthRain': 
'30.5', 'outHumidity': '51', 'outTemp': '24.3', 'pm2_55': '2.1', 
'pm2_55_24h_avg': '1.9', 'pm10': '2.6', 'pm10_24h_avg': '2.6', 
'pressure': '1017.1', 'rain': 'None', 'rainRate': '0.0', 
'relbarometer': '1017.1', 'stormRain': '0.0', 'usUnits': '17', 'UV': 
'0', 'uvradiation': '0.0', 'weekRain': '30.5', 'wh31_ch1_batt': '0', 
'wh31_ch1_sig': '4', 'wh31_ch2_batt': '0', 'wh31_ch2_sig': '4', 
'wh31_ch3_batt': '0', 'wh31_ch3_sig': '4', 'wh45_batt': '6', 
'wh45_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windDir': '205', 
'windGust': '0.0', 'windSpeed': '0.0', 'ws90_batt': '3.22', 
'ws90_sig': '3', 'yearRain': '261.2'


As you can see both the WS90 signal and battery strength are returned
On Wednesday, June 21, 2023 at 7:25:19 PM UTC+1 vince wrote:

I think I'd start by veryifying that the WS90 data you are looking
for is in the weewx database to begin with. What weewx.sdb
elements did you use to store the WS90 battery and signal strength
in ?   How did you define that to happen ?

--
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/f12a759c-0363-427a-ae6d-fc85cb861a12n%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/0f729784-5361-7698-24c4-255d857ac777%40gmail.com.

Re: [weewx-user] Re: WS90 Signal Strength And Battery Status

2023-06-21 Thread Rainer Lang


Could you please send (attach as txt file) your whole skin.conf ?
The excerpt you show only means that certain sensor labels get a 
different name - it doesn't mean that these sensors are shown somewhere.


You have to understand how weewx works and what needs to be done for 
certain observations (sensor values) to appear in the Seasons skin.


a) current values are shown in the left hand side table - and are 
defined in the file current.inc which will be included into the 
index.html file
by the index.html.tmpl file when the report(s) are generated - there 
only something will be shown which is defined already in current.inc

if something hasn't been defined there, you will have to add it there

b) historical values (day, week, month, year) are generated from the 
data archived (written into the weewx database) at the end of each 
archiving cycle

(usually 300 seconds = 5 minutes).
Only the values for which a database field exists can be shown in the 
graphs or in the high/low table (under the current values).
Which database fields are available can be seen in the ws_extended.py 
database schema to be found under /usr/share/weewx/schemas *).
Observations/fields which are not in there cannot be shown. If you want 
to show them, you either have to extend the ws_extended database schema 
or use (=repurpose) an existing field which is not used by your sensors 
(see the field map in the gw1000 driver WiKi and compare to the 
ws_extended database schema). When repurposing an unused database field, 
you have to assign your wanted observation to that field - and when 
showing it in the report use the name of this repurposed field.
This must happen in weewx.conf in the [[StdCalibrate]] [[[Corrections]]] 
section.


In skin.conf you have to "activate" this/these field/s (new database 
field or repurposed field) by including it into the list of observations 
which are supposed to be shown.


My suggestion is that you print out for yourself the 4-5 files 
current.inc, hilo.inc. weewx.conf, skin.conf and index.html.tmpl (on 
separate pages) and see how they work together
weewx.conf --> skin.conf ---> index.html.tmpl (inluding current.inc and 
hilo.inc - and a few more not so relevant right now)
The report and image generators work these files in that sequence and 
create the reports based on these configuration files


Compare this with the result that your configuration files produce right 
now.
Then identify the lines where the observations (fields, variables) are 
mentioned are where the ones you want to have have to be added.

In the first step forget about the database and the pictures.
Just focus on the current values (current.inc) - they can be shown 
without having been saved before into the database.


Next step is to identify the place where the observations (fields, 
variables) have to be added in skin.conf and in index.html.tmpl
For them to be added the database fields need to exist (either new 
database column or repurposed database column/field)


This story is somewhat complex but without understanding what needs to 
be done where and why you will not succeed.
(or you explain what exactly you want to do and find someone who writes 
for you all the entries/lines to be added for your result to come up
and you just copy this into your configuration files and do the database 
extension or repurposing,
and/but you have no clue what was done and why - and next time you want 
to add something you find yourself in the same boat you are in now)


*) if you have a weewx installation via setup.py the path is different - 
see the basic weewx documentation for details (www.weewx.com)

On 21.06.2023 17:13, weewx-user wrote:


Sorry *SKILL SET *is low
On Wednesday, June 21, 2023 at 4:09:31 PM UTC+1 weewx-user wrote:

I am using a Ecowitt GW2000 with an WS90 outdoor sensor.

https://multinet.org.uk/weewx/

It is mostly setup as I would like it but for the life of me I
can't get the WS90 signal strength or battery status to show up
under sensors. This is what I have in the skin.conf

[Labels]

    # Override some labels. No need to identify these as a "Battery"
    # or "Voltage", because that is included in the template.
    [[Generic]]
        wh31_ch1_batt = Bedroom (WH31)
        wh31_ch2_batt = Loft (WH31)
        wh31_ch3_batt = Conservatory (WH31)
        ws90_batt = Main Sensor (WS90)
        wh57_batt = Lightning (WH57)
        ws90_sig = Main Sensor Signal (WS90)

Could someone give me some very simple (my skin set is quite low)
pointers please.

--
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/db9e94d3-1fbf-4bb9-96da-3be8db8c1508n%40googlegroups.com

Re: [weewx-user] adding mm to daily rainfall

2023-06-21 Thread Rainer Lang

At the end of the day it doesn't matter where the weewx.sdb is located - 
as long as weewx and wee_database via weewx.conf and sqlite3 via the 
path in the command know/are told

where it is located.

You can still check with sqlitebrowser what your entry in your database 
for the respective EPOCH timestamp is (see my earlier mail) - and you 
can change it manually
(provided you start it with sudo sqlitebrowser /var/lib/weewx/weewx.sdb 
[in your case]).

That's the pragmatic approach.

Of course you can still try to figure out why your SQL command doesn't 
seem to have been successful.


On 21.06.2023 13:24, Δημήτρης Βήχος wrote:

my database is on /var/lib/weewx/weewx.sdb

metfm@metfm:~$ ls -ail /var/lib/weewx
σύνολο 18692
264962 drwxr-xr-x 1 root root       18 Ιουν 21 14:20 .
   269 drwxr-xr-x 1 root root      592 Φεβ  26 18:30 ..
270727 -rwxrwxrwx 1 root root 19140608 Ιουν 21 14:20 weewx.sdb
metfm@metfm:~$

Στις Τετάρτη 21 Ιουνίου 2023 στις 11:49:35 π.μ. UTC+3, ο χρήστης gjr80 
έγραψε:


No. The default Debian based distro database is
/var/lib/weewx/weewx.sdb. The archive directory is only used (by
default) for setup.py installs.

OP. Have you confirmed the location (and name) of your WeeWX
database? What does the following command show:

$ ls -ail /var/lib/weewx

Gary

On Wednesday, 21 June 2023 at 09:28:58 UTC+1 stefanos...@gmail.com
wrote:

It should be /var/lib/weewx/archive/weewx.sdb

Can you give us a screenshot where the weewx.sdb is??

Στις Τετ, 21 Ιουν 2023, 11:03 ο χρήστης Δημήτρης Βήχος
 έγραψε:

debian installed. also triyng with sudo sqlite3
/var/lib/weewx/weewx.sdb same thing.

Στις Τετάρτη 21 Ιουνίου 2023 στις 9:55:34 π.μ. UTC+3, ο
χρήστης gjr80 έγραψε:

Have you customised your WeeWX install? You appear to
be using a package install so unless you have changed
it your WeeWX database should be in /var/lib/weewx not
/var/weewx.

Gary

On Wednesday, 21 June 2023 at 05:48:19 UTC+1
hobbyl...@gmail.com wrote:

the commands with semi-colons. send me (with sudo
also and with suo su )

metfm@metfm:~$ sudo sqlite3 /var/weewx/weewx.sdb
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> SELECT dateTime, datetime(dateTime,
'unixepoch','localtime'), usUnits, rain FROM
archive WHERE dateTime > 1686881600 AND dateTime
<= 1686981600;
Error: unable to open database
"/var/weewx/weewx.sdb": unable to open database file
metfm@metfm:~$

without semi-colons database open

metfm@metfm:~$ sudo sqlite3 /var/weewx/weewx.sdb
[sudo] password for metfm:
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> select datetime, datetime(dateTime,
'unixepoch','localtime'), rain from archive where
dateTime > 1686881600 and dateTime <= 1686981600
   ...> update archive set rain=12.6 where
dateTime = 1686975900
   ...> .quit
   ...>
metfm@metfm:~$ sudo wee_database --rebuild-daily
--from=2023-06-17 --to=2023-06-17
[sudo] password for metfm:
Using configuration file /etc/weewx/weewx.conf
Using database binding 'wx_binding', which is
bound to database 'archive_sqlite'
Daily summary for 2023-06-17 will be rebuilt.
Proceed (y/n)? y
Rebuilding daily summaries in database 'weewx.sdb' ...
Processed 276 records to rebuild 1 daily summary
in 0.12 seconds
Rebuild of daily summaries in database 'weewx.sdb'
complete
metfm@metfm:~$ sudo /etc/init.d/weewx start
Starting weewx (via systemctl): weewx.service.
metfm@metfm:~$
  but after restarting weewx no change in
database. no 12.6 plus mm who i needs
Στις Τρίτη 20 Ιουνίου 2023 στις 2:10:28 μ.μ.
UTC+3, ο χρήστης gjr80 έγραψε:

At a guess I would say your sqlite3 commands
were never executed due to missing semi-colons
at the end of each sqlite3 command line. Your
commands are basically fine, but you need to
be careful with the

Re: [weewx-user] adding mm to daily rainfall

2023-06-20 Thread Rainer Lang


at first glance looks ok to me -
but what I would do is:
download and install sqlitebrowser (suso apt-get install sqlitebrowser)
start it in update mode
sudo sqlitebrowser /var/weewx/weewx.sdb
and then go to your time stamp and add the values manually in the database
(don't forget to move the cursor to another field once you have filled 
in your new data before pressing the write changes button in the menu: 
File --> write changes)
also, check your database entries for rain, they may be in inches, so 
the 12.6 mm need to be divided by 25.4 before entering into the database 
field)

afterwards run wee_database (between the archiving times !)
sudo wee_database --rebuild-daily --date=2023-06-17
after the next archiving cycle the rain data should show (in the weekly 
and monthly view)
you may have to delete the weekly and monthly pictures from your 
reporting folder as weewx creates new entries only every half-day or 
daily for the longer periods beyond daily.


Maybe your update worked but only the weekly/monthly pictures and 
high/low data were not updated in the report yet


a restart of weewx should not be needed

On 20.06.2023 08:04, Δημήτρης Βήχος wrote:
here is me commands in terminal . trying to plus 12.1 missing mm  in 
17 july  total rainfall


metfm@metfm:~$ sudo sqlite3 /var/weewx/weewx.sdb
[sudo] password for metfm:
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> select datetime, datetime(dateTime, 'unixepoch','localtime'), 
rain from archive where dateTime > 1686881600 and dateTime <= 1686981600

   ...> update archive set rain=12.6 where dateTime = 1686975900
   ...> .quit
   ...>
metfm@metfm:~$ sudo wee_database --rebuild-daily --from=2023-06-17 
--to=2023-06-17

[sudo] password for metfm:
Using configuration file /etc/weewx/weewx.conf
Using database binding 'wx_binding', which is bound to database 
'archive_sqlite'

Daily summary for 2023-06-17 will be rebuilt.
Proceed (y/n)? y
Rebuilding daily summaries in database 'weewx.sdb' ...
Processed 276 records to rebuild 1 daily summary in 0.12 seconds
Rebuild of daily summaries in database 'weewx.sdb' complete
metfm@metfm:~$ sudo /etc/init.d/weewx start
Starting weewx (via systemctl): weewx.service.
metfm@metfm:~$

something missing? something im doing wrong? the exetra mm never shows 
in weewx restarting and updating.




Στις Σάββατο 17 Ιουνίου 2023 στις 12:11:40 μ.μ. UTC+3, ο χρήστης 
Stefanos Kalaitzis έγραψε:


First find the range of time(epoch)  that you want to add the rain
Enter to weeex.sdb

sudo sqlite3 /home/weewx/archive/weewx.sdb

Then check what values your station recorded

 select datetime, datetime(dateTime, 'unixepoch','localtime'),
rain from archive where dateTime > 1686881600 and dateTime <=
1686981600;

Then correct the time you want
For example

update archive set rain=1.0 where dateTime = 1686975900;

Then exit the db

.quit

Stop weewx

After all corrections rebuild the data base for that day


sudo /home/weewx/bin/wee_database --rebuild-daily
--from=2023-06-17 --to=2023-06-17

Start weewx
Thats what i am doing when i have to add some missing mm in my db



Στις Σάβ, 17 Ιουν 2023, 11:42 ο χρήστης Δημήτρης Βήχος
 έγραψε:

i want like to add some mm to my daily rainfall beacuse after
power loss , my console (fine offset) have 10mm above the
weewx after the power on again.
i had loss 10mm in my daily rain.

thank you!

-- 
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/e96ce7e9-1085-46f6-adf4-b82275bf4df4n%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/1f9b1e17-6df0-4bc5-93b6-159f33bd1d12n%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/a553e788-a0c1-9796-8fb4-ca77e7c3e035%40gmail.com.

Re: [weewx-user] Wee_import key error:'cm_per_hour'

2023-06-19 Thread Rainer Lang



in your field map, try to put
rainRate    = rainRate, mm_per_hour
# instead of rainRate = rainRate, mm

and make sure in your weewx.conf under
[StdReport]
[[Defaults]]
[[[units]]]
groups
# you have defined
 group_rainrate = mm_per_hour

On 20.06.2023 05:41, Joao Pedro wrote:

Hii guys :)

Weewx : 4.10.2

I try to use wee_import but i've a little problem:

"pi@raspberrypi:~ $ wee_import --import-config=/home/pi/csv.conf --dry-run
Using WeeWX configuration file /etc/weewx/weewx.conf
Starting wee_import...
A CSV import from source file '/home/pi/weewx.csv' has been requested.
Using database binding 'wx_binding', which is bound to database 'weewx'
Destination table 'archive' unit system is '0x10' (METRIC).
Missing derived observations will be calculated.
All WeeWX UV fields will be set to None.
All WeeWX radiation fields will be set to None.
This is a dry run, imported data will not be saved to archive.
Starting dry run import ...
Traceback (most recent call last):
  File "/usr/share/weewx/wee_import", line 900, in 
    main()
  File "/usr/share/weewx/wee_import", line 830, in main
    source_obj.run()
  File "/usr/share/weewx/weeimport/weeimport.py", line 421, in run
    _mapped_data = self.mapRawData(_raw_data, self.archive_unit_sys)
  File "/usr/share/weewx/weeimport/weeimport.py", line 982, in mapRawData
    _conv_vt = convertStd(_vt, unit_sys)
  File "/usr/share/weewx/weewx/units.py", line 1489, in convertStd
    return StdUnitConverters[target_std_unit_system].convert(val_t)
  File "/usr/share/weewx/weewx/units.py", line 919, in convert
    new_val_t = convert(val_t, new_unit_type)
  File "/usr/share/weewx/weewx/units.py", line 1454, in convert
    conversion_func = conversionDict[val_t[1]][target_unit]
KeyError: 'cm_per_hour'"



My csv config

# EXAMPLE CONFIGURATION FILE FOR IMPORTING FROM CSV FILES
#
# Copyright (c) 2009-2019 Tom Keffer  and Gary 
Roderick.

# See the file LICENSE.txt for your rights.

##

# Specify the source. Available options are:
#   CSV - import obs from a single CSV format file
#   WU - import obs from a Weather Underground PWS history
#   Cumulus - import obs from a one or more Cumulus monthly log files
#   WD - import obs from a one or more WD monthly log files
# Format is:
#   source = (CSV | WU | Cumulus)
source = CSV

##

[CSV]
    # Parameters used when importing from a CSV file

    # Path and name of our CSV source file. Format is:
    #   file = full path and filename
    file = /home/pi/weewx.csv

    # The character used to separate fields. Format is:
    #   delimiter = 
    # Default is , (comma).
    delimiter = ;

    # If there is no mapped interval field how will the interval field be
    # determined for the imported records. Available options are:
    #   derive - Derive the interval field from the timestamp of 
successive
    #            records. This setting is best used when the imported 
records
    #            are equally spaced in time and there are no missing 
records.

    #   conf   - Use the interval setting from weewx.conf. This setting is
    #            best used if the records to be imported have been 
produced by
    #            WeeWX using the same archive interval as set in 
weewx.conf on

    #            this machine.
    #   x      - Use a fixed interval of x minutes for every record. This
    #            setting is best used if the records to be imported are
    #            equally based in time but there are some missing records.
    #
    # Note: If there is a mapped interval field then this setting will be
    #       ignored.
    # Format is:
    #   interval = (derive | conf | x)
    interval = conf

    # Should the [StdQC] max/min limits in weewx.conf be applied to the
    # imported data. This may be useful if the source has extreme 
values that

    # are clearly incorrect for some observations. Available options are:
    #   True  - weewx.conf [StdQC] max/min limits are applied.
    #   False - weewx.conf [StdQC] max/min limits are not applied.
    # Format is:
    #   qc = (True | False)
    qc = True

    # Should any missing derived observations be calculated from the 
imported

    # data if possible. Available options are:
    #   True  - Any missing derived observations are calculated.
    #   False - Any missing derived observations are not calculated.
    # Format is:
    #   calc_missing = (True | False)
    calc_missing = True

    # Specify how imported data fields that contain invalid data (eg a 
numeric
    # field containing non-numeric data) are handled. Available 
options are:
    #   True  - The invalid data is ignored, the WeeWX target field is 
set to

    #           None and the import continues.
    #   False - The import is halted.
    # Format is:
    #   ignore_invalid_data = (True | False)
    # Default is True.
    ignore_invalid_data =

Re: [weewx-user] Re: bad strike count data 4,000+ strikes, how to remove from database or ignore such data in charts

2023-06-13 Thread 'Rainer Lang' via weewx-user


you should read and apply the proper synthax:

try wee_database --help
and apply 
when you mention weewx.conf then as --config=/etc/weewx/weewx.conf
if you have only one database and one respective weewx.conf, you don't 
need to mention it (but you can, however, then correctly)


(sudo) wee_database --drop-daily
and
(sudo) weew_database --rebuild-daily
should suffice

if you want to mention weewx.conf, then:
(sudo) wee_database --drop-daily --config=/etc/weewx/weewx.conf
etc

On 13.06.2023 22:46, Kevin Crivelli wrote:
I was able to delete the entries from the database using the guide 
provided at 
https://github.com/weewx/weewx/wiki/Cleaning%20up%20old%20'bad'%20data 
however, when I got to the section for cleaning up the daily summaries 
I ran into an error with the commands provided


wee_database weewx.conf --drop-daily and wee_database weewx.conf 
--rebuild-daily gave me this error


Traceback (most recent call last):
  File "/usr/share/weewx/wee_database", line 1168, in 
    main()
  File "/usr/share/weewx/wee_database", line 187, in main
    config_path, config_dict = weecfg.read_config(options.config_path, 
args)

  File "/usr/share/weewx/weecfg/__init__.py", line 146, in read_config
    config_path = find_file(config_path, args,
  File "/usr/share/weewx/weecfg/__init__.py", line 117, in find_file
    raise IOError("%s is not a file" % file_path)
OSError: weewx.conf is not a file
On Tuesday, June 13, 2023 at 4:12:46 PM UTC-4 Kevin Crivelli wrote:

there were 3 entries over 3,000 strikes in a matter of minutes
that pushed my count to 11,970 for the day. There has to be a way
to remove those entries. please let me know if anyone knows how.

lightning strike error.JPG

On Tuesday, June 13, 2023 at 3:47:46 PM UTC-4 Kevin Crivelli wrote:

I'm not sure how or why it happened but today around 3:25pm I
received a strike count of over 4,000 strikes. Is there a way
to go into the database and remove this entry? or perhaps I
can add a correction in the corrections section if
lightning_strike_count is < 4,000 = none or something?

thanks for any help on this matter. really odd

--
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/889e23f5-eeac-4c0a-9cf9-aab1f564f9f7n%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/a9339a17-8ff1-546a-a58e-18a472995af8%40gmail.com.

[weewx-user] interceptor driver, HP2560 and WS90 [2]

2023-06-13 Thread 'Rainer Lang' via weewx-user


One more thing - regarding mapping and field names

the weewx names to map to are the database field names of the database 
schema you use for your database
(nowadays usually wview-extended - look up the schema in 
/usr/share/weewx/schemas/wview-extended.py)

[or /home/weewx/bin/schemas  depending on your setup]
you have to map the (additional) field names from the interceptor.py to 
the respective weewx (database) fields from wview-extended.py

(either inside the interceptor.py or via a field-map extension)

if you want to store the new fields which are not in the wview-extended 
schema, you will either have to repurpose existing but unused database 
fields

or extend your database schema with the respective columns

On 13.06.2023 19:40, Rainer Lang wrote:


Hi Jason

1. the local API (local Ecowitt Gateway API aka GW1000 API) was never 
implemented in the HP25x0, HP350x, WH2910 consoles => so no such thing 
like depreciation
you want to know which console supports which API, look up 
https://www.wxforum.net/index.php?topic=40730.0 


2. the reason why you may not receive WS90 (piezo rain) data via the 
custom server could be that your WS90 has not been set in the console 
as primary rain device.

gear wheel --> setup (more) --> rain priority (has to be set to piezo).

3. could you run the interceptor driver stand-alone and post here the 
result of one console post ?

(or run weewx in debug = 3 mode and copy from the syslog)

regards

Rainer

On 13.06.2023 02:28, Jason Gibson wrote:

Hi All,

I have been trying to coax rain data out of the WS90 and into weewx.

I assume that the local API is deprecated on the HP2560 as I can't 
appear to get any details out of it on port 45000.


I am currently using the interceptor driver in listen mode on port 
8080.  And I am able to  log all data in WeeWX except rain from the 
piezo sensor, and battery voltages.


I have tried mapping sensors to fields as below, to no avail, is 
anyone able to assist with the interceptor driver, or is there 
another driver better suited to my hardware?


Hardware:
-
HP2564 - HP2560 & WS90

HP2560_C:
  Hardware revision V2.0
  Firmware: Pro_V1.9.0
  EasyWeatherProv5.11
WS90:
  Firmware 1.3.3

weewx.conf extract:


driver = user.interceptor
    device_type = ecowitt-client
    port = 8080
    iface = ens18
    [[sensor_map_extensions]]
          rain = drain_piezo
          rainRate = rrain_piezo
          bat_wind = wh90batt
          bat_rain = ws90cap_volt

Am I using the right field names?  Example output from the ws90 is as 
follows:


PASSKEY: 
stationtype: EasyWeatherPro_V5.1.1
runtime: 2
dateutc: 2023-06-11 01:53:27
tempinf: 77.0
humidityin: 40
baromrelin: 30.224
baromabsin: 29.946
tempf: 61.2
humidity: 60
winddir: 12
windspeedmph: 5.14
windgustmph: 6.93
maxdailygust: 10.74
solarradiation: 270.64
uv: 2
rrain_piezo: 0.000
erain_piezo: 0.000
hrain_piezo: 0.000
drain_piezo: 0.000
wrain_piezo: 0.000
mrain_piezo: 1.209
yrain_piezo: 1.209
ws90cap_volt: 5.2
ws90_ver: 133
gain10_piezo: 1.15
gain20_piezo: 1.05
gain30_piezo: 1.00
gain40_piezo: 1.00
gain50_piezo: 1.00
wh90batt: 3.10
freq: 433M
model: HP2564CA_Pro_V1.9.0
interval: 30

Cheers,

Jason
--
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/8828c0f2-f040-4558-bf6d-f2ff1dedb0ben%40googlegroups.com 
<https://groups.google.com/d/msgid/weewx-user/8828c0f2-f040-4558-bf6d-f2ff1dedb0ben%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/dc415326-02ca-9b63-8653-5b25318b8e9d%40gmail.com.

Re: [weewx-user] interceptor driver, HP2560 and WS90

2023-06-13 Thread 'Rainer Lang' via weewx-user


Hi Jason

1. the local API (local Ecowitt Gateway API aka GW1000 API) was never 
implemented in the HP25x0, HP350x, WH2910 consoles => so no such thing 
like depreciation
you want to know which console supports which API, look up 
https://www.wxforum.net/index.php?topic=40730.0 


2. the reason why you may not receive WS90 (piezo rain) data via the 
custom server could be that your WS90 has not been set in the console as 
primary rain device.

gear wheel --> setup (more) --> rain priority (has to be set to piezo).

3. could you run the interceptor driver stand-alone and post here the 
result of one console post ?

(or run weewx in debug = 3 mode and copy from the syslog)

regards

Rainer

On 13.06.2023 02:28, Jason Gibson wrote:

Hi All,

I have been trying to coax rain data out of the WS90 and into weewx.

I assume that the local API is deprecated on the HP2560 as I can't 
appear to get any details out of it on port 45000.


I am currently using the interceptor driver in listen mode on port 
8080.  And I am able to  log all data in WeeWX except rain from the 
piezo sensor, and battery voltages.


I have tried mapping sensors to fields as below, to no avail, is 
anyone able to assist with the interceptor driver, or is there another 
driver better suited to my hardware?


Hardware:
-
HP2564 - HP2560 & WS90

HP2560_C:
  Hardware revision V2.0
  Firmware: Pro_V1.9.0
  EasyWeatherProv5.11
WS90:
  Firmware 1.3.3

weewx.conf extract:


driver = user.interceptor
    device_type = ecowitt-client
    port = 8080
    iface = ens18
    [[sensor_map_extensions]]
          rain = drain_piezo
          rainRate = rrain_piezo
          bat_wind = wh90batt
          bat_rain = ws90cap_volt

Am I using the right field names?  Example output from the ws90 is as 
follows:


PASSKEY: 
stationtype: EasyWeatherPro_V5.1.1
runtime: 2
dateutc: 2023-06-11 01:53:27
tempinf: 77.0
humidityin: 40
baromrelin: 30.224
baromabsin: 29.946
tempf: 61.2
humidity: 60
winddir: 12
windspeedmph: 5.14
windgustmph: 6.93
maxdailygust: 10.74
solarradiation: 270.64
uv: 2
rrain_piezo: 0.000
erain_piezo: 0.000
hrain_piezo: 0.000
drain_piezo: 0.000
wrain_piezo: 0.000
mrain_piezo: 1.209
yrain_piezo: 1.209
ws90cap_volt: 5.2
ws90_ver: 133
gain10_piezo: 1.15
gain20_piezo: 1.05
gain30_piezo: 1.00
gain40_piezo: 1.00
gain50_piezo: 1.00
wh90batt: 3.10
freq: 433M
model: HP2564CA_Pro_V1.9.0
interval: 30

Cheers,

Jason
--
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/8828c0f2-f040-4558-bf6d-f2ff1dedb0ben%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/c6b71035-a9ee-7f26-247a-1ac5362caf09%40gmail.com.

Re: [weewx-user] Main loop exiting. Shutting engine down.

2023-05-25 Thread 'Rainer Lang' via weewx-user


1. what do you mean by "I am loosing rain--information." ?
can you please explain more in detail !? What do you lose ?

2. has weewx ever written to the database ?
you say you get an engine shutdown every ten minutes ... - if you use 
the standard archiving interval (5 minutes - 300 seconds), there should 
have been at least one archiving/saving data to the database

we cannot see a respective entry in the syslog

can you restart weewx and provide the full syslog from startup until the 
next retrying !?


On 25.05.2023 21:13, Herbert Eberhardt (Schoaga TV) wrote:
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter stationtype=EasyWeatherPro_V5.1.1
May 25 20:54:34 WetterUbDesk weewx[1103] INFO user.interceptor: 
unrecognized parameter runtime=3
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter baromrelin=29.548
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter maxdailygust=10.29
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter eventrainin=0.000
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter hourlyrainin=0.000
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter weeklyrainin=0.071
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter monthlyrainin=3.157
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter yearlyrainin=8.429
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter freq=868M
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter model=WS2900_V2.01.18
May 25 20:54:34 WetterUbDesk weewx[1103] INFO user.interceptor: 
unrecognized parameter interval=120'
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: rain: 
newtot self.last_rain 0.0 0.0
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: raw 
packet: {'dateTime': 1685040873, 'usUnits': 1, 'temperature_in': 74.3, 
'humidity_in': 49.0, 'pressure': 29.208, 'temperature_out': 60.8, 
'humidity_out': 79.0, 'wind_dir': 349.0, 'wind_speed': 0.0, 
'wind_gust': 0.0, 'solar_radiation': 0.21, 'uv': 0.0, 'rain_rate': 
0.0, 'rain_daily': 0.0, 'rain_total': 8.429, 'wh65_battery': 0.0, 
'rain': 0.0}
May 25 20:54:34 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
mapped packet: {'dateTime': 1685040873, 'usUnits': 1, 'pressure': 
29.208, 'outHumidity': 79.0, 'inHumidity': 49.0, 'outTemp': 60.8, 
'inTemp': 74.3, 'windSpeed': 0.0, 'windGust': 0.0, 'windDir': 349.0, 
'radiation': 0.21, 'rain': 0.0, 'rainRate': 0.0, 'UV': 0.0}
May 25 20:54:44 WetterUbDesk weewx[1103] DEBUG user.interceptor: empty 
queue
May 25 20:56:34 WetterUbDesk weewx[1103] message repeated 11 times: [ 
DEBUG user.interceptor: empty queue]
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: POST: 
b'PASSKEY==EasyWeatherPro_V5.1.1=0=2023-05-25+18:56:34=74.5=49=29.548=29.208=60.6=79=349=0.00=0.00=10.29=0.15=0=0.000=0.000=0.000=0.000=0.071=3.157=8.429=8.429=0=868M=WS2900_V2.01.18=120'
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: raw 
data: 
b'PASSKEY=542BB86DD8E9A93E7BC81DFCD901C0D2=EasyWeatherPro_V5.1.1=0=2023-05-25+18:56:34=74.5=49=29.548=29.208=60.6=79=349=0.00=0.00=10.29=0.15=0=0.000=0.000=0.000=0.000=0.071=3.157=8.429=8.429=0=868M=WS2900_V2.01.18=120'
May 25 20:56:35 WetterUbDesk weewx[1103] INFO user.interceptor: 
unrecognized parameter b'PASSKEY=542BB86DD8E9A93E7BC81DFCD901C0D2
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter stationtype=EasyWeatherPro_V5.1.1
May 25 20:56:35 WetterUbDesk weewx[1103] INFO user.interceptor: 
unrecognized parameter runtime=0
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter baromrelin=29.548
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter maxdailygust=10.29
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter eventrainin=0.000
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter hourlyrainin=0.000
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter weeklyrainin=0.071
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter monthlyrainin=3.157
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter yearlyrainin=8.429
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter freq=868M
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: 
ignored parameter model=WS2900_V2.01.18
May 25 20:56:35 WetterUbDesk weewx[1103] INFO user.interceptor: 
unrecognized parameter interval=120'
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: rain: 
newtot self.last_rain 0.0 0.0
May 25 20:56:35 WetterUbDesk weewx[1103] DEBUG user.interceptor: raw 
packet: {'dateTime': 1685040994, 'usUnits': 1,

Re: [weewx-user] SIGW1100 and Ecowitt WS90 weewx3.9.2 going to upgrade to version 4.XXX

2023-05-24 Thread 'Rainer Lang' via weewx-user

another option would be to use a modified version of Matthew Wall's
Interceptor driver - extend its field map to cover for all data sent by
the customized server function of the Ecowitt consoles.

All Ecowitt console have this function for the sensors they support.
Apart from adaptations to Python3 Matthew doesn't seem to have worked on
the iInterceptor driver for quite a long time - and the Ecowitt sensor
universe has significantly expanded ever since.

Other developers have created already an extended version where the WS90
capacitor voltage is included.

There is a (working !) extention of the Interceptor driver
(interceptor.py) made/adapted by the German developer Werner Krenn (also
a member of the community here) to cover for ALL recent Ecowitt sensors
existing today.

See attachment.
You can experiment with it.
I suggest you do the installation with the basic version first -
https://github.com/matthewwall/weewx-interceptor/

Understand how it works and make it working for you - it's pretty easy
and straightforward
(you can install the interceptor driver in parallel to your GW1000
driver - the entry in the station stanza in weewx.conf decides which
driver (section) you use).
Once it works with the basic sensors (it will create non-fatal error
messages in the syslog for every non-covered sensor), save the original
interceptor.py and replace it by the one in the zip file.

Also add to weewx.conf in your [Accumulator] stanza
[Accumulator]
[[lightning_strike_count]]
extractor = last

That's if you want to use a WH57 lightning sensor together with the
Interceptor driver

If you don't create the non-existing database fields in the
wview_extended database schema (or repurpose existing but unused fields
to accomodate your new sensor data) and use the respective field map
and/or respective entries in the weewx.conf [StdCalibrate]
[[Corrections]] stanza, this data won't be saved/archived and will only
be available as $current between archiving periods.

But that's not a driver issue, it's a user issue. 
You want to save the "extra" data which are not part of the
wview_extended database schema, you have to extend it (or repurpose)

good luck

On 24.05.2023 07:53, Mark Fraser wrote:

On Mon, 22 May 2023, 09:59 zasp...@gmail.com, wrote:

Going to make the big jump form a series 3 weewx to the latest
version are there any pitfalls I should be aware of .

been running the GW1000 driver a couple of weeks works without
issues so far

The WS90 has and onboard capacitor and its logged on the Ecowitt app

does the GW1000 driver log this voltage? or is it just the
battery voltage

Thanks for any advice

It may be worth looking at this fork of the RTL433 driver
https://github.com/jpochmara/weewx-sdr which is supposed to support
the capacitor voltage.

--
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/CAPSrEd%3DVUFHv7FH6b6_X8DjFURDzHDG2Yc4Fy2gtM5ghU3okOg%40mail.gmail.com
.

Re: [weewx-user] New install of Weewx, Raspberry Pi, Apache 2.4.56 - 403 Forbidden

2023-05-22 Thread 'Rainer Lang' via weewx-user

what do you get when you enter just the RaspberryPi IP address in your 
browser ?

you should get the standard webserver page (Apache2 Debian Default Page)
does this work ?

if so, has the folder /var/www/html/weewx been created in the first place ?
can you see the folder in the Raspi File Manager ?
has weewx written the skin files into that directory ? (there should be 
a lot of .png files and the index.html file)


On 22.05.2023 19:53, Peter Hurn wrote:
Thanks I tried the sudo chmod -R 755 /var/www/html/weewx suggested, 
still the same issue unfortunately

You don't have permission to access this resource.

On Friday, 19 May 2023 at 13:50:17 UTC+1 Rainer Lang wrote:

did you change the permissions for weewx web folder

/var/www/html/weewx

or

/home/weewx/public_html

whichever you are using ?

The example for the first path would be

sudo chmod -R 755 /var/www/html/weewx

only then the Apache webserver has the permission to read (and
display) the /var/www/html/weewx folder content

(for a /home/weewx installation the command would be:
sudo chmod -R 755 /home/weewx/public_html )

On 18.05.2023 23:48, Peter Hurn wrote:

Hello,

I am trying to install Weewx fresh on a Raspberry PI, running
Debian Bullseye,
I would like to host the website internally from the Pi,
I have installed Apache 2.4.56 and checked the
default Apache page displays correctly, which it does.

I then followed the Weewx installation which installed.

I then followed the instructions from the wiki article /Configure
a web server (Apache, NGINX or lighttpd)/

<https://github.com/weewx/weewx/wiki/Configure-a-web-server-(Apache,-NGINX-or-lighttpd)>

The section for Apache 2.4 worked however when I try to navigate
to the server address/weewx/ I now receive the following error.

--

Forbidden
You don't have permission to access this resource.

Apache/2.4.56 (Raspbian) Server at (IP) Port 80

-

I have searched but don't seem to be having much luck resolving
the issue, any thoughts?

Kind regards,

Peter.

-- 
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/b43bca91-0b12-42c0-b4db-dc06cfcf1fe0n%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/b43bca91-0b12-42c0-b4db-dc06cfcf1fe0n%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/eb612886-cc2a-4d0d-9c06-1486203b4c13n%40googlegroups.com 
<https://groups.google.com/d/msgid/weewx-user/eb612886-cc2a-4d0d-9c06-1486203b4c13n%40googlegroups.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3c1103e5-b509-6ebc-8998-0580fb95fd8f%40gmail.com.

Re: [weewx-user] SIGW1100 and Ecowitt WS90 weewx3.9.2 going to upgrade to version 4.XXX

2023-05-22 Thread 'Rainer Lang' via weewx-user

As far as I know is the capacitor voltage of the WS90 not communicated
via the local API (Ecowitt Gateway API), only the battery voltage.
The capacitor voltage you can see in the Ecowitt cloud dashboard of your
station/console - that's a different communication protocol between your
console and the Ecowitt cloud.

have a look at Ecowitt Gateway driver WiKi aka GW1000 API driver:
https://github.com/gjr80/weewx-gw1000/wiki/Sensor-battery-states

And, just for clarity, the Ecowitt app doesn't log anything. It reads
the data from the Ecowitt cloud where console has posted them. 

On 22.05.2023 10:59, zasp...@gmail.com wrote:

Going to make the big jump form a series 3 weewx to the latest version
are there any pitfalls I should be aware of .

been running the GW1000 driver a couple of weeks works without issues
so far

The WS90 has and onboard capacitor and its logged on the Ecowitt app

does the GW1000 driver log this voltage? or is it just the battery
voltage

Thanks for any advice

Re: [weewx-user] New install of Weewx, Raspberry Pi, Apache 2.4.56 - 403 Forbidden

2023-05-19 Thread 'Rainer Lang' via weewx-user

did you change the permissions for weewx web folder

/var/www/html/weewx

/home/weewx/public_html

whichever you are using ?

The example for the first path would be

sudo chmod -R 755 /var/www/html/weewx

only then the Apache webserver has the permission to read (and display)
the /var/www/html/weewx folder content

(for a /home/weewx installation the command would be:
sudo chmod -R 755 /home/weewx/public_html )

On 18.05.2023 23:48, Peter Hurn wrote:

Hello,

I am trying to install Weewx fresh on a Raspberry PI, running Debian
Bullseye,

I would like to host the website internally from the Pi,
I have installed Apache 2.4.56 and checked the default Apache page
displays correctly, which it does.

I then followed the Weewx installation which installed.

I then followed the instructions from the wiki article /Configure a
web server (Apache, NGINX or lighttpd)/

The section for Apache 2.4 worked however when I try to navigate to
the server address/weewx/ I now receive the following error.

Forbidden
You don't have permission to access this resource.

Apache/2.4.56 (Raspbian) Server at (IP) Port 80

I have searched but don't seem to be having much luck resolving the
issue, any thoughts?

Kind regards,

Peter.

Re: [weewx-user] WH31L lightning sensor

2023-03-27 Thread Rainer Lang


what console or device does weewx read from ?
which driver/extension are you using for catching the lightning data of 
your Ecowitt WH57/Ambient WH31L ?


On 27.03.2023 12:27, Mark Fraser wrote:
Revisiting my lightning sensor configuration as I've got no graphs on 
the Seasons skin and wondering if I've set it up correctly.


In my sensor map I have:
    strikes_total = strikes_total.52017.FOWH31LPacket
    lightning_distance = distance.52017.FOWH31LPacket
    txBatteryStatus = battery.52017.FOWH31LPacket

[StdCalibrate]

    [[Corrections]]
    lightning_distance = lightning_distance if 
lightning_strike_count > 0 else None


and

[Accumulator]
    [[lightning_distance]]
    extractor = last

When I start up weewx I see
Mar 24 08:54:06 server weewx[537130] INFO user.sdr: deltas is {'rain': 
'rain_total', 'strikes': 'strikes_total'}

in the log.

Is this correct?



--
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/489d3379-17a6-b8f3-9d88-5c5ac35246eb%40gmail.com.

Re: [weewx-user] new to weewx - need help with couple of things...

2023-03-22 Thread Rainer Lang

"but weewx is not reporting any wind data." - what exactly you want to
say by that sentence ?

What driver are you using ?
WHich version of weewx are you using ?
What are your weewx.conf settings for that ?
What does your skin.conf look like ?
I guess by "the white page with graphs and text" you mean the Seasons
skin ...

which skin(s) have you activated in weewx (--> weewx.conf) ?

With answers to these questions we could understand your situation
better and probably give you more hints.

In general there are many weewx skins (web page representations, reporting).
The developers have placed them on github - and usually a documentation
and installation instructions go with them.

On 22.03.2023 06:27, Edgar Arroyo wrote:
Using acurite iris 5-in-1 but no wind data. I was previously using
UnderTheWX on my Mac but decided to move my WX reporting to a
librecomputer and got it setup and working, but weewx is not reporting
any wind data.

I have seen some nice looking pages, how can I install a template
that's nicer than the white page with graphs and text?

Re: [weewx-user] wee_import

2023-03-11 Thread Rainer Lang

can you provide your .conf file and the first three lines of the csv
file (header + 2 data lines) ?

On 11.03.2023 15:33, Willi Dennerlohr wrote:

unfortunately no success

Am Sa., 11. März 2023 um 14:55 Uhr schrieb Rainer Lang
:

convert " , " into "," (without "") e.g. by using find and replace
in Microsoft Excel  - and save as a text file
On 11.03.2023 14:51, Willi Dennerlohr wrote:

The csv-import does not work:
Type-Error: "delimitter" must be a 1-character string.
In the conv - file und csv - file is the delimitter a " , ".
What can I do?
--
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/9b2690bc-593b-4cee-b438-00b551e50728n%40googlegroups.com

<https://groups.google.com/d/msgid/weewx-user/9b2690bc-593b-4cee-b438-00b551e50728n%40googlegroups.com?utm_medium=email_source=footer>.

--
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/YK090sHaud8/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/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.com

<https://groups.google.com/d/msgid/weewx-user/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.com?utm_medium=email_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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/CALo2f9B4qBghh4akwsJmEp1RnfdGTqoVo6zaiBadLFdWRtxFdg%40mail.gmail.com
<https://groups.google.com/d/msgid/weewx-user/CALo2f9B4qBghh4akwsJmEp1RnfdGTqoVo6zaiBadLFdWRtxFdg%40mail.gmail.com?utm_medium=email_source=footer>.

Re: [weewx-user] wee_import

2023-03-11 Thread Rainer Lang

convert " , " into "," (without "") e.g. by using find and replace in 
Microsoft Excel  - and save as a text file

On 11.03.2023 14:51, Willi Dennerlohr wrote:

The csv-import does not work:
Type-Error: "delimitter" must be a 1-character string.
In the conv - file und csv - file is the delimitter a " , ".
What can I do?
--
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/9b2690bc-593b-4cee-b438-00b551e50728n%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/962ba8ac-0911-2b03-b534-a0f7498afcd2%40gmail.com.

Re: [weewx-user] wee_import - dateTime not converting/importing properly

2023-03-11 Thread Rainer Lang


try

raw_datetime_format = %Y%m%d%H%M (that you already have)

and in the field map just

datetime = RecDate

assuming RecDate is the header name of the date/time - drop the 
unix_epoch addition


if it still doesn't work, please provide the header line and the 
complete first 2 lines of your import file


On 11.03.2023 11:37, William wrote:

Hi,

I'm trying to import historical data into my new weewx installation. 
Following the documentation and the sample import config, I can't seem 
to get the date and time to parse correctly. I'm using weewx version 
4.10.2 and wee_import version 0.7, as both were pulled down through 
the apt package repository today.


In my archive data, my date and time are stored in a RecDate field and 
uses the format mmddHHMM. Example: 201105060957 would be more 
appropriately readable as 2011-05-06 09:57.


In the import configuration file I have raw_datetime_format = 
%Y%m%d%H%M, and in the FieldMap stanza, dateTime = RecDate, unix_epoch.


When I do a dry run on a single record, it shows a wild date (year 
8342!) with the message:


Unique records processed: 1; Last timestamp: 8342-10-07 16:55:57 EDT 
(201105060957)


When I run it on a different data set it sees 202303110321 as 
timestamp: 8380-09-24 00:25:21 EDT


Am I missing something in the config? I'm fairly certain the Python 
strptime format is correct, and have tested it in a Python script:

dateTime = datetime.strptime('201105060957', '%Y%m%d%H%M')

returns
datetime.datetime(2011, 5, 6, 9, 57)
Any feedback would be greatly appreciated. Thank you!
--
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/42a18d84-9140-42c1-9172-c417f42659cfn%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/41524a5f-a2f7-2a26-9857-1bcb8f58b459%40gmail.com.

[weewx-user] GW1100 and WN34BL

2023-02-25 Thread Rainer Lang


I think I mentioned the WN34 sensor mapping to extraTemp9-16 earlier ...
and
I would not map extraTemp9 to extraTemp1, because then you risk to mess 
up your database in case you start adding WH31 sensors 1-8 later which is

something many Ecowitt users do.
there is a imho better way for mapping using the wxview-extended 
database schema: using the 4 unused soilTemp database fields

so I would add in weewx.conf in the stanza
[StdCalibrate]
   [[Corrections]]
  soilTemp1 = extraTemp9
and add soilTemp1 to the [DisplayOptions] stanza in the Sesons skin 
skin.conf
that would then make weewx save/archive the WN34 Ch1 sensor values to 
soilTemp1 and keept the extraTemp1-8 free for the WH31 sensors.


That works perfectly for me

soilTemp in the Ecowitt ecosystem are sensors (8 though) which are 
related to the WN34 soil temperature or WN34 liquid (e.g. water) 
temperature.
The WN34 sensors don't provide humidity values whereas the WH31 sensors 
(extraTemp1-8) do. Once more reason to better use soilTemp1-4 for the 
first four WN34 sensors.

On 25.02.2023 03:33, gjr80 wrote:
Just to be clear about relbarometer. Ecowitt gateway devices provide 
two pressure values, the first is what Ecowitt refers to as /absolute 
barometer/ which is what we know as gauge or station pressure (what 
the driver refers to as absbarometer and what WeeWX knows as the WeeWX 
field pressure), the second is what Ecowitt refers to as /relative 
barometer/. /relative barometer/ (what the driver knows as 
relbarometer) is an approximation to barometric pressure (what WeeWX 
knows as WeeWX field barometer) as it does not correct for 
temperature. The default mapping used by the Ecowitt gateway driver is 
to map the device absbarometer field to the WeeWX field pressure, the 
device field relbarometer is not mapped to WeeWX field barometer, 
rather it is mapped (or passed through) as relbarometer (this way 
WeeWX calculates barometer using a more sophisticated formula that 
does compensate for temperature and altitude and at the same time 
gives the user access to the Ecowitt approximated /relative barometer/ 
field). The price you pay for this is that WeeWX needs 12 hours of 
pressure data before it can calculate barometer. Since barometric 
pressure is what most weather reports use and also what most folks 
display on web pages, you probably don't want to display pressure or 
relbarometer, just be patient and barometer will appear once you have 
12 hours of pressure data.


You may find the WeeWX wiki page What is the difference between 
barometer, pressure and altimeter ? 
 
provides useful background.


By all means adjust the Ecowitt relative barometer value to suit, 
though for all intents and purposes this value is only used by 
Ecowitt, it is not used by WeeWX.


In terms of extraTemp9, Vince is correct in that this is your first 
WN34x sensor temperature data. This is indeed by design. The Ecowitt 
gateway devices support many different sensor types and then on top of 
this multiple sensors (or channels) of most types. The driver could 
certainly attempt to automatically map these sensors/channels to the 
fields in the WeeWX schema, but this would have lead to some quite 
complex code as well as causing a support nightmare. Instead I decided 
to default map sensors to a fixed WeeWX field (eg the first WN34 
channel is always mapped to extraTemp9) and give the user the ability 
to alter this default mapping by defining a new field map or 
extending/altering the existing field map. In the OPs case WeeWX is 
most likely using the wview_extended schema which only includes 
extraTemp1 to extraTemp8. You essentially have two options; either 
change the default mapping to map the WN34 data to some other WeeWX 
field in the wview_extended schema (using a [[field_map_extensions]] 
entry) or adding the extraTemp9 field to the database. In either case 
you may or may not need to make changes to the [DisplayOptions] stanza 
in the Seasons skin config file (skin.conf). Just remember, for WeeWX 
to save data to database two basic conditions must be met; first the 
data must exist in a field in WeeWX generated archive records and 
second the same field name must exist in the in-use database schema.


A similar situation exists with sensor battery and signal state data 
as does with extraTemp9, though is the case of sensor battery stay and 
signal data the field names used in the default field map are more 
self evident due to the use of sensor model and channel number in the 
field name in most cases.


The Ecowitt gateway driver wiki is far from complete, but if your 
system includes more than just the gateway device and an x-in-1 sensor 
suite I would suggest you become very familiar with the default field 
map used by the driver. This is covered on the Field map page 
 in the driver wiki.


Gary
--
You received this

1 2 3 >

1 - 100 of 253 matches

Mail list logo