On command *lsusb* the following response
Bus 001 Device 002: ID 0483:5750 STMicroelectronics
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Op maandag 10 februari 2020 19:30:49 UTC+1 schreef Olivier Guyotot:
>
> I haven't touched this in a while (it's just running on its own
Sorry, only use hPa here so the obvious nonsense inHg value was lost on me.
WeeWX is flexible enough that you change whatever you want to display on
your web page, you can use another field or recalculate using whatever you
like, it's just a case of altering the appropriate template. Similarly,
Hi all,
I'm a new weewx user using it on an old RPi running a Raspbian wheezy. In
your opinion, do the fousb drivers for the FineOffset WH 1080 SE work well
with the pyusb 1.0.2? Thanks in advance for the answer.
--
You received this message because you are subscribed to the Google Groups
"wee
Ok, have new data logger installed and everything seems to be working as
expected. I did have to do the following to get everything started but
once I did that it's been working for 12 hours now. It appears I had a bad
datalogger.
I had to enter...
wee_device --clear-memory
wee_device --start
a
Am Montag, 10. Februar 2020 14:55:18 UTC+1 schrieb Thomas Keffer:
>
> Skins have been backwards compatible for years and rarely have a problem
> with an upgrade. There's no reason why a French skin written for V2.0 back
> in 2012 wouldn't work with V4.0.
>
> -tk
>
>
Well, in github there are tw
I know this is not a WeeWX issue but can I get some guidance...
Over the years I seem to get signal quality at 0, often. I'm not moving
the console, in fact I get the same thing on a console and a envoy in the
same location.
The console is approximately 25 feet from the station and I can see t
You may have to ask Davis about this one. I would guess there could be
problems with interference from neighbors, perhaps even another ISS.
Another possibility is a failing supercap or battery in your ISS.
But, you should ask Davis.
-tk
On Tue, Feb 11, 2020 at 7:48 AM Troy Lass wrote:
> I kno
I don't know why the author of the French translation chose to have two
versions. Perhaps to take advantage of a feature in V3.8?
On Tue, Feb 11, 2020 at 7:28 AM Vetti52 wrote:
> Am Montag, 10. Februar 2020 14:55:18 UTC+1 schrieb Thomas Keffer:
>>
>> Skins have been backwards compatible for year
Ok, I'll open a ticket with Davis
Just a couple more data items...
I live in a rural area on 35 arces with few neighbors. There are no power
lines or other obvious concerns. One of my neighbors does have a Davis
station on iss1, which I can get a signal to and the station over 300 yards
aw
I have confirmed and to the best of my knowledge, the station altitude is
set correctly (altitude = 2320 foot).
When I run weewx directly (sudo weewxd weewx.conf) I get the following:
Traceback (most recent call last):
File "/usr/bin/weewxd", line 64, in
weewx.engine.main(options, args)
Troy Lass writes:
> Over the years I seem to get signal quality at 0, often. I'm not moving
> the console, in fact I get the same thing on a console and a envoy in the
> same location.
>
> The console is approximately 25 feet from the station and I can see the
> station in a clear line of sig
The link in Gary’s mail explains how to run it — just give the full path to the
config file as an argument to weewxd. Something like:
sudo weewxd /etc/weewx/weewx.conf
-Les
> On Feb 11, 2020, at 9:21 AM, Dan Blanchard wrote:
>
>
> I have confirmed and to the best of my knowledge, the
Thanks, Greg. Nice to hear from an expert!
On Tue, Feb 11, 2020 at 9:47 AM Greg Troxel wrote:
> Troy Lass writes:
>
> > Over the years I seem to get signal quality at 0, often. I'm not moving
> > the console, in fact I get the same thing on a console and a envoy in
> the
> > same location.
> >
What am I missing here?
String in my iss_all.json file:
#set global $iss_all = [["Tue Feb 11 10:54 am","SW/10","NE/9","69","6min
45sec"],["Tue Feb 11 12:31 pm","W/10","NE/9","33","6min 16sec"],["Tue Feb
11 02:09 pm","WNW/10","ENE/9","28","6min 3sec"],["Tue Feb 11 03:46
pm","WNW/10","E/9","72","6mi
Alright, so the good news is that the vendor_id and product_id are still
the same.
NOTE: I just noticed that in your configuration, you specified driver =
user.hp3000. Unless you made a change, it should be driver = user.ws3000.
Assuming that you installed the driver correctly in the bin/user d
Thanks for the direction, will give this a try once I can get back on my
home network.
On Monday, February 10, 2020 at 8:07:57 PM UTC-8, Paul McGeorge wrote:
>
>
> You could start by trying $current.soilMoist1 in your current.inc file if
> your using the seasons skin. Read the customization gui
First of all, thanks for sticking with me on this. I apologize for my
denseness on this matter. I am apparently not running the proper weewxd;
I've tried sudo weewxd /etc/weewx/weewx.conf and get nothing. I do not know
how to see what pressures are being include in loop packet and archive
rec
What is nothing? Does it just return to the command prompt? Can you post a
screenshot of the exact command entered and the entire response.
Gary
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving em
Cheetah doesn't like $pass as a variable name. It must confuse Cheetah,
there's a #pass directive. Try a different variable name there.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails fro
pass is a reserved word. It's a statement with a meaning of its own so
the python interpretor does not understand its use as a variable name.
Rename it to something else - iss_pass ?
On 12/02/2020, Kevin Davis wrote:
> What am I missing here?
>
> String in my iss_all.json file:
> #set global
Ugh, duh. Thanks.
On Tue, Feb 11, 2020 at 12:48 PM Glenn McKechnie
wrote:
> pass is a reserved word. It's a statement with a meaning of its own so
> the python interpretor does not understand its use as a variable name.
>
> Rename it to something else - iss_pass ?
>
> On 12/02/2020, Kevin Da
Olivier,
Puzzled, because apparently weewx has been installed in my configuration in
a different way than you expect.
See the inserted text.
;-( Some more thinking to be done ...
Waiting for your next suggestions.
Anton
Op dinsdag 11 februari 2020 20:17:29 UTC+1 schreef Olivier Guyotot:
>
> Al
Screen shot attached
On Tuesday, February 11, 2020 at 12:30:30 PM UTC-8, gjr80 wrote:
>
> What is nothing? Does it just return to the command prompt? Can you post a
> screenshot of the exact command entered and the entire response.
>
> Gary
>
--
You received this message because you are subscri
Olivier,
Perhaps the underlaying Linux_version makes a difference.
In my configuration it is Raspian_Buster_Lite.
Anton
Op dinsdag 11 februari 2020 22:29:08 UTC+1 schreef Ton vanN:
>
> Olivier,
>
> Puzzled, because apparently weewx has been installed in my configuration
> in a different way tha
That is bizarre, but sudo weewxd weewx.conf still gives a reaction and
error. Nothing appears in the log?
Gary
On Wednesday, 12 February 2020 08:33:55 UTC+10, Dan Blanchard wrote:
>
> Screen shot attached
>
> On Tuesday, February 11, 2020 at 12:30:30 PM UTC-8, gjr80 wrote:
>>
>> What is nothing?
OK, and what happens if you shutdown/kill all running instances of WeeWX.
Gary
On Wednesday, 12 February 2020 08:48:43 UTC+10, Dan Blanchard wrote:
>
> I've attached the latest log and new screenshot
>
> On Tuesday, February 11, 2020 at 2:40:04 PM UTC-8, gjr80 wrote:
>>
>> That is bizarre, but su
Have checked the other Raspberries within my reach whether they have a
folder /bin/user/
Result:
Raspian_Stretch => no folder /bin/user/
Raspian_Buster_Desktop => no folder /bin/user/
Op dinsdag 11 februari 2020 23:36:05 UTC+1 schreef Ton vanN:
>
> Olivier,
>
> Perhaps the underlaying Linux_versi
Your issue (to do with file locations) is due to the way in which WeeWX was
installed. Installation via setup.py results in WeeWX files being located
in /home/weewx by default. Installation via a package results in the WeeWX
files being spread over a number of different locations. Refer to Wher
Gary,
Completely agree.
After the experiments, this evening checked the location of weewx-files,
and that is 100% in accordance with http://www.weewx.com/docs/debian.htm
as could be expected, because the installation was also in accordance with
that document.
Also at my Raspberry weewx_root is /
Do you mean sudo /etc/init.d/weewx stop
On Tuesday, February 11, 2020 at 2:55:34 PM UTC-8, gjr80 wrote:
>
> OK, and what happens if you shutdown/kill all running instances of WeeWX.
>
> Gary
>
> On Wednesday, 12 February 2020 08:48:43 UTC+10, Dan Blanchard wrote:
>>
>> I've attached the latest log
Yes, that will shutdown a well behaved WeeWX service. Try that to start
with.
Gary
On Wednesday, 12 February 2020 09:58:21 UTC+10, Dan Blanchard wrote:
>
> Do you mean sudo /etc/init.d/weewx stop
>
> On Tuesday, February 11, 2020 at 2:55:34 PM UTC-8, gjr80 wrote:
>>
>> OK, and what happens if yo
OK, I shut down via sudo /etc/init.d/weewx stop then I ran sudo weewxd
/etc/weewx/weewx.conf and it is continuing to produce data. I see that the
barometer and altimeter are both the 32.xx readings while pressure is the
same as what is reading on my station 29.9x.
Can I ge weewx to read the pr
On Wednesday, 12 February 2020 10:16:47 UTC+10, Dan Blanchard wrote:
>
> OK, I shut down via sudo /etc/init.d/weewx stop then I ran sudo weewxd
> /etc/weewx/weewx.conf and it is continuing to produce data. I see that
> the barometer and altimeter are both the 32.xx readings while pressure is
>
The further I go, the more complex it is getting. First, yes I have a
WS-2813U-IT and yes, I did set the relative pressure to match the local
weather service.
I don't want to muddy the waters any more, but how is it that I stopped the
wewx service but it is still reporting? I'm still trying t
sudo /etc/init.d/weewx stop will stop the current running service but if
you have other instances running, for example WeeWX directly, sudo
/etc/init.d/weewx
stop will have no effect as WeeWX is not running as a service. When running
WeeWX directly you need to stop the execution using a control
check that the absolute pressure is correct - I have had a FO station which
had a dodgy pressure sensor before now. Calibrating pressure in weewx
solved it.
On Wednesday, 12 February 2020 03:51:29 UTC+2, gjr80 wrote:
>
> sudo /etc/init.d/weewx stop will stop the current running service but if
I have just finished writing a utility to copy files to an S3 bucket, which
I based on ftpupload.py in the weevil directory.
This is now working perfectly when I call it with hard coded values, but
when I add the code at the bottom to get the variables from weewx.conf I
get the following error
I have written a report to copy files to an AWS S3 bucket, separate thread
on that, but now an trying to incorporate it into my deployment.
The easy way, and the way I have done it so far is to modify
reportengine.py, but there must be a better way
#
==
38 matches
Mail list logo
