upgrade from b16 very smooth, took seconds. i have one venv shared by two
stations
(venv) graham@wx:~$ sudo systemctl stop weewx@vantage weewx@ecowitt
——
(venv) weewx@wx:~$ python3 -m pip install weewx --upgrade
Requirement already satisfied: weewx in ./venv/lib/python3.11/site-packages
(5.0.0b
first reaction is: ok for folk’s own code but a nightmare for supported code
⊣GE⊢
> On 14 Dec 2023, at 10:46 am, Tom Keffer wrote:
>
> We should probably continue to ignore 'None' type errors. It's difficult for
> a newbie to write an expression that can handle them.
--
You received this mess
the license for using public domain software includes a requirement to provide
acknowledgements of and easy access to the relevant source code. perhaps no
public domain code (such as weewx) was used
⊣GE⊢
> On 10 Sep 2023, at 7:38 am, Steven Sheeley wrote:
>
> Most likely so that he can monitiz
': '22.5', 'inHumidity': '48', 'inTemp':
'19.2', ‘lightning_distan
[snip]
⊣GE⊢
> On 7 Sep 2023, at 1:54 am, Tom Keffer wrote:
>
> Right you are.
>
> This is because weectl device is actually implemented as a wrapper around
i have several stations, none of them using the default name. weectl device
seems to ignore —config directive:
(venv) weewx@wx:~/ecowitt$ weectl device --help
Unable to find file 'weewx.conf'. Tried directories ['/home/weewx/weewx-data',
'/etc/weewx', '/home/weewx']
(venv) weewx@wx:~/ecowitt$ we
minor V5 bug:
weewx:~ $ weectl station create —config=station1/weewx.conf
(using relative filename) creates everything fine except it sets WEEWX_HOME to
station1 in weewx.conf, so
weewx:~ $ weewxd —config=station1/weewx.conf
runs fine until it crashes when tries to generate a report:
ngen
ash script daily that captures info on WeeWx and use a query
> like this to get yesterday's info in what i'm interested in
> ERRORS="journalctl -q -u weewx.service --since yesterday --until today -g
> 'ERROR' "
> thanks
> Paul
>
>
>
> O
i have been playing with debian bookworm, where rsyslog is no longer in the
core and has to be installed (if you use it). i would describe that as a ’new’
dependency for weewx under debian
the weewx 5.0 re-packaging looks awesome - i have now tried pip-installing it
under bookworm
i have also
#x27;s no special "update" permission like there
> is on MySQL. Or, do you mean something else?
>
> On Mon, May 22, 2023 at 8:11 PM Graham Eddy <mailto:g...@geddy.au>> wrote:
>> write perm on directory for sqlite3 updates?
>> ⊣GE⊢
>>
>>> On
write perm on directory for sqlite3 updates?
⊣GE⊢
> On 23 May 2023, at 7:22 am, Tom Keffer wrote:
>
> This is surely a straightforward permissions and ownership issue.
--
You received this message because you are subscribed to the Google Groups
"weewx-development" group.
To unsubscribe from t
i agree that this is what is being asked for, which is some kind of free-format
description of altitude in local quirky dialect (i exaggerate for effect).
i think what is presently provided is the correct approach i.e. unequivocal in
a supported weewx unit system
⊣GE⊢
> On 28 Mar 2023, at 12:36
i do similar but there are mixed results when browser client (eg laptop)
offline for a while, so ensure a prominent timestamp indicating last refresh
i don’t think we have the problem of millions of leeches needlessly sucking
server bandwidth...
⊣GE⊢
> On 23 Jan 2023, at 6:37 am, Paul Dunphy w
writing log is just sequential; not sure if sqlite3 hits some critical, core
database blocks over & over but weewx essentially writes sequentially into
tables. it will be interesting to see on tom’s forever machine which expires
first - a critical RPI component or the SD’s pool of spare blocks
in practice i do same (copy of 180MB uncompressed db in cron-controlled daily
backups to local file share), but it is so quick i just time it to miss a weewx
archive update without stopping it. but i also copy the db itself offsite once
daily (to internet web server)
> On 8 Aug 2022, at 10:51 a
litre"= " l",
lux" = " lx",
mbar = " mbar"
mbar_per_hour = " mbar/h"
_
Graham Eddy
> On 14 Nov 2021, at 11:42, Graham Eddy wrote:
>
> that fixed the IndexErr
that fixed the IndexError crashing cheetah while generating Seasons, and files
are generated without errors
now what i see in the generated files is US units, whereas i selected metric
units during clean install.
same config files as i submitted last time; i can resubmit for convenience
(i know
i am getting cheetah errors on a clean install, preventing Seasons skin
from generating
RPi reinstalled linux, new weewx beta7 installed using setup.py, chose
simulator driver
only changes from fresh install:
* config file renamed simulator.conf, and it uses sqlite3 file
simulator.sdb and mod
perhaps make user demonstrate sufficient knowledge by making a few changes
(e.g. setting up PATH) before setup.py successfully executes? force users who
cannot show enough knowledge (or initiative to learn) to package install for
support reasons
> On 22 Apr 2021, at 3:20 pm, 'Cameron D' via wee
, at 12:23 pm, Vince Skahan wrote:
>
> On Wednesday, April 21, 2021 at 6:50:03 PM UTC-7 Graham Eddy wrote:
> (the default on RPi is that $HOME/bin is added to PATH if it exists, so
> /home/weewx/bin gets picked up automatically when log in as weewx)
>
>
> Not true in any ve
another argument in favour of a dedicated user for weewx software. all my weewx
software runs as user ‘weewx’; i log in as weewx when i have a work session on
it
(the default on RPi is that $HOME/bin is added to PATH if it exists, so
/home/weewx/bin gets picked up automatically when log in as we
i favour the collection of sensors approach as compared to the centralised
weather station approach
suppose the weewx driver was just a heartbeat - creates an empty LOOP packet
with a timestamp. then all data sources would be a service that insert their
data since last heartbeat. but, compared
so the rumour of an API for GW1000 and an early adopter program was true!
with news of your API-based driver-in-making i have just placed an order
for GW1003 + lightning range + 2*soil moisture + 2*air quality sensors, and
i'll be happy to help with the testing
i saw that the API supports multi
it is better to think of the database as a service sink near the end of the
conveyor belt - your job is to insert stuff near the start of the conveyor
belt. have your external apps talk to data services (create them, if no-one
else has created suitable adapters yet) to inject your values
beside
macos? fits the OS/release/cpu tuple.
g-eddy
> On 11 May 2020, at 9:30 am, Greg Troxel wrote:
>
> So the notion that a binary package in rpm, deb, whatever can be
> installed on any linux flavor that has the same CPU type is basically
> unsound; it would have to be built per OS/release/cpu tuple
having moved to 4.0.0/python3.7 last night i see a couple of anomalies i did
not notice in testing.
the following one is mainly cosmetic but i think i have a fix for it
uptime_os (in the “About Station” part of Season skin) presently reports
obviously incorrect value:
Server uptime
18393 days, 0
i have just installed github and pycharm - haven’t used either before.
i have cloned weewx into my pycharm environment and started my own private
branch.
how do i sync the current changes underway on 4.0.0 into my copy, or does this
happen magically in background?
secondly, what’s the correct pr
true. just a collection of data sources (and sinks) now, we have abstracted
away from the hardware, term “driver” is just historical leftover.
the packet is just a train with data getting on and off along the way
> On 8 May 2020, at 11:09 pm, Greg Troxel wrote:
>
> The driver/service distinctio
e use of python’s logging package, given that syslog is
completely useless on mac osx. i have been using logging package in my own
python code for a while
cheers
____
Graham Eddy
--
You received this message because you are subscribed to the Google Groups
"weewx-development" group.
T
great! that fixed the conversion problem
nearly there. is there some way to tell whether METRICWX or US is the
required unit system for the email message? (apart from the obvious, which
is to make it a weewx.conf parameter).
thanks
On Tuesday, 30 April 2019 21:29:57 UTC+10, Tom Keffer wrote:
>
i tried the above and i am missing something...
it gives an attribute error for a well-known unit. clues would be welcome.
cheers
my code snippet:
# Create a Metric ValueHelper for the metric
t_vt = weewx.units.as_value_tuple(record, metric)
t_vh = weewx.units.ValueHelper(t_vt
in the example alarm.py, it prints the test expression verbatim inside the
email.
how do i get it to use the skin to get converted value and units to put in
the email?
note that this is outside the Cheetah conversion context of StdReport etc.
cheers
31 matches
Mail list logo
