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

['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?

--
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/00ee8aba-985b-4a0a-b5bf-2d2b35e226ffn%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/8c4a3b87-315c-5945-61ef-a387d62dbd6f%40gmail.com.

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

[Greg Troxel]

"'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.
Meaured voltage (mine says 4.55V right now) is really nice to have since
it is so granular, but it could be turned into 95% by dividing by
1.6V*3.  Yes I know nominal is 1.5V, but fresh alkalines are usually
1.6V roughly.  Or you could divide by 4.5V instead, and thus be over
100%, and be more clearly connected to the raw data.  Either is fine and
on reflection I'd go with 4.5V.

I have mapped ISS battery status in Home Assistant so that

  1 (low) leads to 0%
  0 (ok) leads to 100%

via

- name: "Davis ISS battery raw"
  state_topic: "weather/loop"
  state_class: measurement
  expire_after: 330
  value_template: "{{ value_json.txBatteryStatus }}"
- name: "Davis ISS battery"
  state_topic: "weather/loop"
  state_cla

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

['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.
Meaured voltage (mine says 4.55V right now) is really nice to have since
it is so granular, but it could be turned into 95% by dividin

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

[Greg Troxel]

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

> @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.

We have to live with it in driver code, but nobody else does.

I agree that it's a mess, but my point is that by defining a battery
status protocol where 0% is just about empty and 100% is full, and an
"are we on external power" protocol as 0/1, we can map all sorts of
things -- not just EcoWitt -- into this, and then people that want to
display battery status can rely on the 0-100% and not/external without
having to understand the device, either at the skin code level or the
brain level.

120% is not a proper representation for the WH45.  Yes, it's 6 in the
on-air bits, but EcoWitt consoles/displays do not show 6 bars.  They
show some sort of "external power" indication, per the rtl_433 comment
(which must have come from someone with such a display helping testing
or writing the code).

> 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

That is a step in the right direction, but it still results in a
non-uniform representation which needs special case processing rather
than one which can be handled with one chunk of computer or wetware
code.

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

[weewx-user] NOAA Reports

[Kit Knox]

Good morning!

I looked around and was unable to find answer on my own - I'm looking for 
some help with the NOAA reports link for weewx using the belchertown skin: 
I have report links that go back to 1969 but I only have data for the last 
few years. I see some others have just a few years on their pages; how do 
you trim the list to only offer data that's available?

Thank you for our time. :0)

--Kit

-- 
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/e97dc294-efbd-4db9-973e-cba8e1e76e1en%40googlegroups.com.

[weewx-user] 4.10.2 Vantage Pro 2 : no received from Vantage console

[Matthias Manhart]

I try to connect my Vantage Pro 2 with weewx 4.10.2 running on a raspberry 
pi 4. The VP2 is connected via RS232 and an adapter to USB (directly 
plugged into the pi4). Currently the same connection is used with a 
raspberry pi 3 and the software Meteohub without any problems.

Weewx detects the VP2 and starts with the communication, but after the 
initial part i see the error "*send_data: no  received from Vantage 
console*".

Any idea, why the initial part is ok and than the error is shown ?

Regards Matthias

Part of the weewx.conf:

[Vantage]
# This section is for the Davis Vantage series of weather stations.
   
# Connection type: serial or ethernet
#  serial (the classic VantagePro)
#  ethernet (the WeatherLinkIP or Serial-Ethernet bridge)
type = serial
   
# If the connection type is serial, a port must be specified:
#   Debian, Ubuntu, Redhat, Fedora, and SuSE:
# /dev/ttyUSB0 is a common USB port name
# /dev/ttyS0   is a common serial port name
#   BSD:
# /dev/cuaU0   is a common serial port name
port = /dev/ttyUSB0
   
# If the connection type is ethernet, an IP Address/hostname is 
required:
host = 192.168.10.224
   
##
# The rest of this section rarely needs any attention.
# You can safely leave it "as is."
##
   
# Serial baud rate (usually 19200)
baudrate = 19200
   
# TCP port (when using the WeatherLinkIP)
tcp_port = 5500
   
# TCP send delay (when using the WeatherLinkIP):
tcp_send_delay = 0.5
   
# The type of LOOP packet to request: 1 = LOOP1; 2 = LOOP2; 3 = both
loop_request = 3
   
# The id of your ISS station (usually 1). If you use a wind meter 
connected
# to a anemometer transmitter kit, use its id
iss_id = 1
   
# How long to wait for a response from the station before giving up (in
# seconds; must be greater than 2)
timeout = 6
   
# How long to wait before trying again (in seconds)
wait_before_retry = 2.0
   
# How many times to try before giving up:
max_tries = 10
   
# Vantage model Type: 1 = Vantage Pro; 2 = Vantage Pro2
model_type = 2
   
# The driver to use:
driver = weewx.drivers.vantage

Start of the log-file:

Aug 14 17:50:53 testx weewx[1580] INFO __main__: Initializing weewx version 
4.10.2
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Using Python 3.9.2 
(default, Feb 28 2021, 17:03:44) #012[GCC 10.2.1 20210110]
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Located at /usr/bin/python3
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Platform 
Linux-6.1.45-v8+-aarch64-with-glibc2.31
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Locale is 'de_CH.UTF-8'
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Using configuration file 
/home/weewx/weewx.conf
Aug 14 17:50:53 testx weewx[1580] INFO __main__: Debug is 2
Aug 14 17:50:53 testx weewx[1580] DEBUG __main__: Initializing engine
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Driver 
version is 3.5.2
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Option 
loop_request=3
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Opened up 
serial port /dev/ttyUSB0; baud 19200; timeout 6.00
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Successfully 
woke up Vantage console
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Hardware 
type is 16
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: ISS ID is 1
Aug 14 17:50:53 testx weewx[1580] DEBUG weewx.drivers.vantage: Hardware 
name: Vantage Pro2
Aug 14 17:50:54 testx weewx[1580] DEBUG weewx.wxservices: Calculations for 
LOOP packets: {'pressure': 'prefer_hardware', 'altimeter': 
'prefer_hardware', 'appTemp': 'prefer_hardware', 'barometer': 
'prefer_hardware', 'cloudbase': 'prefer_hardware', 'dewpoint': 
'prefer_hardware', 'ET': 'prefer_hardware', 'heatindex': 'prefer_hardware', 
'humidex': 'prefer_hardware', 'inDewpoint': 'prefer_hardware', 
'maxSolarRad': 'prefer_hardware', 'rainRate': 'prefer_hardware', 
'windchill': 'prefer_hardware', 'windrun': 'prefer_hardware', 'windDir': 
'software', 'windGustDir': 'software'}
Aug 14 17:50:54 testx weewx[1580] DEBUG weewx.wxservices: Calculations for 
archive records: {'pressure': 'prefer_hardware', 'altimeter': 
'prefer_hardware', 'appTemp': 'prefer_hardware', 'barometer': 
'prefer_hardware', 'cloudbase': 'prefer_hardware', 'dewpoint': 
'prefer_hardware', 'ET': 'prefer_hardware', 'heatindex': 'prefer_hardware', 
'humidex': 'prefer_hardware', 'inDewpoint': 'prefer_hardware', 
'maxSolarRad': 'prefer_hardware', 'rainRate': 'prefer_hardware', 
'windchill': 'prefer_hardware', 'windrun': 'prefer_hardware', 'windDir': 
'software', 'windGustDir': 'software'}
Aug 14 17:50:54 testx weewx[1580] INFO weewx.wxservices: StdWXCalculate 
will use data binding wx_binding
Aug 14 17:50:54 testx weewx

[weewx-user] Re: 4.10.2 Vantage Pro 2 : no received from Vantage console

[vince]

I would unplug the USB and plug it back in.   Use the 'dmesg' command to 
see if it sees the device being unplugged and re-plugged.

Use the 'lsusb' command to see what is connected to your pi.

-- 
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/103957c7-7064-4ba3-9f72-a7e2447ac2d3n%40googlegroups.com.

[weewx-user] Re: NOAA Reports

[vince]

You have old data in your database from weewx running before your clock was 
corrected by ntpd or systemd.

See the wiki article "
https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data" for the 
procedure to fix things.

You want to search for dateTime < 10 which is in 2001 so it should 
be a reasonable starting point.

I would suggest installing ntp rather than relying on systemd to keep the 
clock in synch (sudo apt-get install ntp)

-- 
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/ad18e484-c16b-4385-a552-6eb10925ecdan%40googlegroups.com.

[weewx-user] SolarEdge PV API

[Dan'l B]

Just got a new SolarEdge monitoring system running and looking for ways to 
display its data in WeeWx. It looks as if I might have several options 
 and I'm wondering if anyone here 
has explored this project.

-- 
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/dcd61c91-e9ed-420c-9e8b-f2f23a2a232en%40googlegroups.com.

[weewx-user] Re: 4.10.2 Vantage Pro 2 : no received from Vantage console

[Matthias Manhart]

Der Befehl lsusb gibt folgende Angaben:

Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA 
Technology Corp. JMS578 SATA 6Gb/s
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
*Bus 001 Device 003: ID 0557:2008 ATEN International Co., Ltd UC-232A 
Serial Port [pl2303]*
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Beim Aus- und wieder Einstecken erhalte ich in dmesg diese Angaben:

[  137.795913] usb 1-1.3: USB disconnect, device number 3
[  137.796272] pl2303 ttyUSB0: pl2303 converter now disconnected from 
ttyUSB0
[  137.796319] pl2303 1-1.3:1.0: device disconnected
[  140.929549] usb 1-1.3: new full-speed USB device number 4 using xhci_hcd
[  141.033597] usb 1-1.3: New USB device found, idVendor=0557, 
idProduct=2008, bcdDevice= 0.01
[  141.033631] usb 1-1.3: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[  141.038414] pl2303 1-1.3:1.0: pl2303 converter detected
[  141.048247] usb 1-1.3: pl2303 converter now attached to ttyUSB0

vince schrieb am Montag, 14. August 2023 um 19:12:42 UTC+2:

> I would unplug the USB and plug it back in.   Use the 'dmesg' command to 
> see if it sees the device being unplugged and re-plugged.
>
> Use the 'lsusb' command to see what is connected to your pi.
>
>

-- 
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/cdb3a316-2566-4f14-9862-ceaadae48e4bn%40googlegroups.com.

[weewx-user] GW1000 Ecowitt Gateway and WeeWx 5.0

[gert.a...@gmail.com]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/407782c5-8d42-4cdf-ac3b-425d14f47ea7n%40googlegroups.com.

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

[vince]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0f6e85bd-f238-4504-8c07-9a7b0dce094dn%40googlegroups.com.

Re: [weewx-user] Re: WDC Skin

[David Bätge]

I assume you are using the current version 3.3.0? The error indicates that 
WeeWX can not find 
the search_list_extensions user.weewx_wdc.WdcGeneralUtil. 

Any chance you are using an old skin.conf file? Please compare 
with https://github.com/Daveiano/weewx-wdc/blob/v3.3.0/skins/weewx-wdc/skin.conf
Or, perhaps, have you overwritten the  search_list_extensions  config for 
the skin via weewx.conf?

Would be great if you could post the relevant section from weewx.conf and 
your current skin.conf so I could have a look.

Eirik Skorstad schrieb am Sonntag, 13. August 2023 um 23:04:37 UTC+2:

> Evaluation of template /home/weewx/skins/weewx-wdc/index.html.tmpl failed.
> 2023-08-13T23:00:40.303871+02:00 odin weewx[251007] ERROR 
> weewx.cheetahgenerator:  Ignoring template 
> /home/weewx/skins/weewx-wdc/index.html.tmpl
> 2023-08-13T23:00:40.304352+02:00 odin weewx[251007] ERROR 
> weewx.cheetahgenerator:  Reason: cannot find 'get_windrose_enabled'
> 2023-08-13T23:00:40.304456+02:00 odin weewx[251007] ERROR 
> weewx.cheetahgenerator:  To debug, try inserting '#errorCatcher Echo' 
> at top of template
>
>
> Skin is not generating any of the templates. Why is that? 
> torsdag 8. juni 2023 kl. 11:22:50 UTC+2 skrev Greg from Oz:
>
>> Yes that works.
>> I did a grep of the whole directory and sub directories looking for that 
>> and missed it.
>> But I was looking for get_base_path and not just base_path
>>
>> Thanks again.
>>
>> On Thursday, 8 June 2023 at 19:05:48 UTC+10 David Bätge wrote:
>>
>>> Hi Greg!  Please set the base_path in skin.conf to '/wdc/':
>>>
>>> base_path = /wdc/
>>>
>>> See 
>>> https://github.com/Daveiano/weewx-wdc/wiki/WeeWX-related#setting-html_root-and-basepath
>>>  
>>> and https://github.com/Daveiano/weewx-wdc/wiki/Configuration#extras. 
>>> This should resolve the problem.
>>> Greg from Oz schrieb am Donnerstag, 8. Juni 2023 um 10:53:53 UTC+2:
>>>
 Hi,

 I am testing the wdc skin and have set the html document root to 
 /var/www/html/weather/wdc
 If I go to https://weather.ubeaut.work/wdc/ (because I am testing and 
 want to leave my other webpages) it shows the wdc index.html which is good.
 If I click on any of the menu items eg Today  week month it takes me to 
 my other web page. Yesterday doesn't work because on my other webpage 
 there 
 isn't a yesterday web page.
 I suspect it is because of the $get_base_path which would be 
 https://weather.ubeaut.work in this case.
 How or where can I change this to be https://weather.ubeaut.work/wdc 
 so I can test it out?

 Thanks


 On Monday, 3 April 2023 at 00:31:31 UTC+10 gary@gmail.com wrote:

> Version 3.1.1 has been released and this is now one of the nicest 
> skins I've used.
> Clear text, excellent graphs, histograms, live data from MQTT.
> Scales well to tablets.
> For my needs, replaced the Belchertown skin.
> On Friday, August 5, 2022 at 10:43:52 AM UTC-4 Andrea Di Saverio wrote:
>
>> Sorry for my late replay.
>>
>> Yes, the suggestion solved my problem. I was not installing as root 
>> user.
>> Thank you.
>>
>> Il giorno giovedì 4 agosto 2022 alle 01:46:26 UTC+2 
>> david@gmail.com ha scritto:
>>
>>> @disaveri Did this solve your problem?
>>>
>>> Btw: I released 2.0.1 which resolves the "non-web-root"-issue, the 
>>> "Pressure diagram with inHg unit"-issue and includes a few other 
>>> bugfixes: 
>>> https://github.com/Daveiano/weewx-wdc/releases/tag/v2.0.1
>>>
>>> Thanks for your input!
>>>
>>> vince schrieb am Dienstag, 2. August 2022 um 00:54:05 UTC+2:
>>>
 On Monday, August 1, 2022 at 3:32:23 PM UTC-7 disaveri...@gmail.com 
 wrote:

>  the root cause is possibly something else?
>

 Yes.  The 'root' cause indeed. 

 See the  FAQ - 
 https://github.com/weewx/weewx/wiki/faq-permission-denied
  

>>>

-- 
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/db4eac93-de0d-4e36-9155-3b4fd9883564n%40googlegroups.com.

[weewx-user] A fix for mosquito access outside of local machine

[Neville Davis]

Hi 

I have started to update my files in my i2C sensor config and have included 
a link to that folder below. 
Just incase no-one has seen the fix for some issues with mosquito access 
outside of your local machine I have included that in the first parts of my 
update.
This link will contain files not only for weewx, but also for my solar 
system, power and water consumption (I live only with rainwater tanks).
I will be leaving my older files still available as they may help others.

https://bit.ly/3KE7t53

Nev

-- 
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/57d7921b-686c-4c03-b87c-db76f55ceb5cn%40googlegroups.com.

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

[gert.a...@gmail.com]

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+unsubscr...@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.

[weewx-user] Re: SolarEdge PV API

[michael.k...@gmx.at]

I have have something running with a Fronius inverter. I don't know which 
option the SolarEdge provides on site and I don't know the API. But two 
option to get the data into weewx come to my mind:

   - creating an extension and polling the inverter
   - find a way to let the inverter emit MQTT messages and use MQTTSubscribe 
   

For my Fronius inverter I came up with polling the inverter every 
archive_interval, which also works for backfilling historical 
data: https://github.com/mKainzbauer/weewx_extensions/blob/master/fronius.py
Dan'l B schrieb am Montag, 14. August 2023 um 19:35:52 UTC+2:

> Just got a new SolarEdge monitoring system running and looking for ways to 
> display its data in WeeWx. It looks as if I might have several options 
>  and I'm wondering if anyone 
> here has explored this project.
>

-- 
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/68aeddf9-c41e-41e6-9b1d-e737a1deef75n%40googlegroups.com.

Re: [weewx-user] weewx can't update data from netatmo no more

['neu...@bnjpro.dk' via weewx-user]

This fix has been running uninterrupted from the day I implemented it. So 
happy with it. :-)

But I noticed that there has apparently always been a nismatch between the 
data netatmo has, and the data that is API'ed to Weewx for rain meassures.

There should be someone who has fixed the issue, I think. I can't find it 
right now though. But are you aware of anybody who has fixed this issue AND 
this authentication as well?

tirsdag den 18. juli 2023 kl. 10.40.10 UTC+2 skrev Stefan Gliessmann:

> Awesome!
>
> Glad I was of help :)
>
> On Tue, Jul 18, 2023 at 10:20 AM 'neu...@bnjpro.dk' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> It works.
>>
>> Thank you Stefan, it made my day. :-)
>>
>> mandag den 17. juli 2023 kl. 21.17.17 UTC+2 skrev neu...@bnjpro.dk:
>>
>>> Thank you Stefan, this looks like a good solution. I will try it out 
>>> tomorrow. :-)
>>>
>>>
>>> mandag den 17. juli 2023 kl. 15.34.08 UTC+2 skrev Stefan Gliessmann:
>>>
 a friend is using netatmo, too.

 take a look here:

 https://oe7drt.com/posts/2023-07-15-update-weewx-netatmo-extension/

 On Monday, July 17, 2023 at 11:38:47 AM UTC+2 Rainer Lang wrote:

> 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&client_id=64b0ea9f090b11190f07b867&client_secret=Haf1qozNFvLMjpjp64cSpgiuPY3IYm4BlPb8zp7EmjlL&username=neumann%
> 40bnjpro.dk&password=SECRET&scope=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?
>
> -- 
> 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/b75a72cd-6c53-49ed-98a8-03e52a7634a2n%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/XpT98FO3i5w/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/07c41b85-19ef-4e79-9b69-609a4428ad6an%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/84b1ac1a-2b49-45eb-b40c-5bbad0a3a71bn%40googlegroups.com.

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

['Ian Millard' via weewx-user]

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 VinceI followed the installation guide for the driver, but the installation used the folder structure from WeeWx version 4.RgdsGertOn 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:HiIs it possible to install the gateway with WeeWx 5.0ThanksGert



-- 
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/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/E0E36273-3A90-488C-A6E1-0C5835834243%40btinternet.com.