I had the same problem. A bit of research shows that I needed to edit the
/etc/init.d/weewx file so that the
# Required-Start:
line contains '$network'.
This is converted by the tools that translate the SysVInit code to
'systemd' code to wait until the network is operational.
Susan
On
I'm using weewx 3.6.2 and it has been working well on my RPi (even with my
custom driver).
I have recently started sending data to WOW and I've noticed that the wind
direction is always 'NNE' and that the wind speed (which is displayed in
knots on WOW) is always much higher than on the standard
Thanks for the replies. I mean the weewx generated 'standard report'.
I've also just seen that the 'weewx.conf' section for [StdReport]
[[StandardReport]] [[[Units]]] Groups has a 'group_pressure' entry
that is set for 'mbar' so I'll try setting that when I get home. (I assume
that this
I am running weewx 3.6.2 on a RPi using the standard report.
I can't find where to change the web output to show 'hPa' for the pressure
measurements, instead of 'mbar'. I've tried 'skin.conf' under
'group_pressure' and in 'units.py' (the definition of 'MetricUnits' and
'MetrixWXUnits' for
Waiting until today did the trick for the graphics.
As gjr80 mentioned, the NOAA monthly report is still wrong but now I knwo
how to sort that out as well.
Thanks everyone
Susan
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe
Thanks - I managed to get that to work.
At first I tried just setting the values to 0 but I needed to set them to
NULL (as per the instructions - I know!!!) before the next report would set
the 'Month' displays to sensible values.
However the 'Year' summaries is still out. Is there an
>
> Thanks for the response. I tried this but it doesn't seem to solve my
> situation. When I do a reboot of the RPi, this is what happens:
>
I just looked further back in this thread to see what OS you are running .
I see you are running Debian 8.0 ( take it that is 'Jessie') and I'm
running
On Thursday, March 23, 2017 at 1:39:36 PM UTC+11, vk3...@gmail.com wrote:
>
> Looks like you are using systemd - in that case I had this problem until I
> asses the lines to the .service. file to wait until everything necessary
> is started. From memory this is the file system, network time
I've played with the SenseHAT (but on a RPi3) and you may need to
compensate for the fact that the chip heats up the SenseHAT and so it shows
a higher than actual temperature reading. I've seen this mentioned in
several places on the Web and there are suggestions about how to compensate
for
Just a word of caution - there is more to the tide than just the location
of the sun and moon. The local coastline and bathymetry play a bit part and
can change times by some hours.
When I worked for the local meteorological organisation, I found that it
was not at all straight forward to
If you are trying to use the network to send to WeatherUnderground, then
you may need to wait for it to start as well.
Something like:
Requires=Network-online.target
After=Network-online.target
if I remember correctly.
Susan
--
You received this message because you are subscribed to the
Sorry - I didn't mean to make the 'N' a capital but I'm not sure if it
matters.
Susan
On Thursday, August 24, 2017 at 12:32:56 PM UTC+10, vk3...@gmail.com wrote:
>
> If you are trying to use the network to send to WeatherUnderground, then
> you may need to wait for it to start as well.
>
>
You are replying to a post of mine that is very out of date and my
misunderstanding was corrected shortly after I posted.
In fact, if you look under the drivers section of the Wiki you will find
the HP1000 driver that I wrote that uses the Wifi connection directly from
Weewx to gather data
Thanks Glenn - there were lots of such entries in the Melbourne (where I
am) xml file. Deleted teh xml files and all is well again.
I noticed that I was getting errors from other BOM files a couple of days
ago as well - they seem to be having a few problems lately (their main
radar broke in
Weewx has just started to create this error:
Dec 1 17:51:04 weather weewx[20911]: cheetahgenerator: Generate failed
with exception ''
Dec 1 17:51:04 weather weewx[20911]: cheetahgenerator: Ignoring
template /home/weewx/skins/Responsive/forecast.html.tmpl
Dec 1 17:51:04 weather
Unless you specifically want your RPi to be a DHCP server for WiFI devices,
I suggest that you stop the 'dhcpcd' service.
The commands:
sudo systemctl stop dhcpcd
sudo systemctl disable dhcpcd
should do the trick. (The first stops the service running if it is, and the
second stops is
You can get around the issue with the clock by switching from the old
'init.d' approach to the systemctl equivalent. (With the versions of
Raspbian - which I assume you are using on the RPi - any files in the
'init.d' directories are automatically converted to a (roughly) equivalent
systemctl
Personally I'd be checking on what is causing the 'freezing' because, if it
is something like running out of space for the ram-disk based log files (as
happened to me once), or the lack of space on the SD card (not necessarily
from WeeWx itself but from other files being written) or even a
I was not aware of that map - any my station is not on it (not that I
really want to make it public - I would need to make 2 interfaces to keep
the 'internal' data private)
Therefore it may not be a truly representative sample of what skins (or
anything else) is out there.
Susan
--
You
One thing to be aware of is that the heat from the ARM chip can bias the
temperature sensor in the Hat - it did with mine when running on an RPi3
and could well with other (earlier) boards that run a little cooler.
Therefore I'd suggest that you add in a way to calibrate your sensors
before
Jessie actually converts everything to use the systemctl service. There is
a specific "generator" app that runs early in the bootstrap process that
reads all of these 'init.d' files and creates a (supposedly) equivalent
.service file for systemctl.
I'm not exactly sure where these generated
As the author of the HP1000 driver I have not tested it on anything other
than the HP1000/WS1001/ that I have and some
other users have found works for them.
It relies on being able to connect to the console over the network, and for
the packets being exchanged with the console to be of
I just tried the Colin's site and the map is centred on my lat/long
(Melbourne, Australia).
Looking at the web page source, I can see it passing the Wellington
lat/long to windy.com so it must be picking my location up from somewhere
else.
Susan
--
You received this message because you are
In my HP1000 weewx driver, I use the formula (in Python)
int(round(data_value)/256)
where data_value is the value I read directly from the device itself.
The resulting values seem to match those displayed on the console itself.
Susan
--
You received this message because you are subscribed to the
You are not being a nuisance at all, but it is a bit hard to do 'remote
diagnostics'.
The log file would be useful but not the whole thing: just the part a bit
before you start weewx until just after it has stopped will be enough.
Where are you setting the loop delay value and can you show us
Mmmm - I'll have a look to see if there is an issue with the delay setting.
I've had a look at the log file and I can't see any reason why it should
just stop like that. I fact, how do you know that it *has* stopped? Can you
do a 'ps' or 'top' to se if the process is still running, or if you
Hello Graham,
I've not been able to come up with anything so far but I'm still looking at
this. It is a real puzzle because there should be log file entries from
WeeWx if my code was exiting or encountering a fault etc.. Instead there is
nothing in the log file.
I'm still looking into
Simple answer is : no.
The driver starts by doing a broadcast using the net mask to ask the
weather station console to respond with its IP address. This type of
broadcast cannot cross subnets (i.e. it is not routable) and also assumes
that the router will allow the broadcast to pass through
That indicates that you have not followed the instructions for installing
the driver and configuring the 'weewx.conf' file.
Susan
On Thursday, April 19, 2018 at 4:38:24 AM UTC+10, Damjan Hajsek wrote:
>
> I also tried HP1000 driver as it was suggested by some use, but get this
> error.
>
> Apr
First off, my apologies to all - given the subject line I completely missed
that this question was related to my HP1000 driver.
Given the line number, you are using the latest version of the driver (I
note that the driver that Bob provides above is based on the earlier
version).
Is it possible
G - too long since I wrote the code and I made a stupid mistake. The
two 'loginf' lines should read
loginf('Bad data: length = {0}'.format(len(rxData)))
loginf('Bad data: "{0}"'.format(rxData))
I've attached your file with the correction in it.
Sorry about that.
Susan
--
You received
Not sure if this answers your questions but... if you want a way of
accessing your device when the IP address changes, what about using DDNS.
I know that you use your NAS differently to mine, but I have a Synology
NASas well and they provide a DDNS service so I can talk to the NAS from
OK - I found the problem and the underlying fault is mine (as usual)!
What was happening is, during the startup phase, the driver was reading the
'historic' records from the weather station. It reads these in batches and
then processes therm into the database (and any other places that Weewx
The entry to the drive (whichis the root for weewx) is:
x.x.x.x:/volume1/weewx/home/weewx nfs
defaults,nofail,noatime,nolock,intr 0 0
Of course the first part is the reference to the NAS folder
Susan
--
You received this message because you are subscribed to the Google Groups
I have Weewx running on a RPi (zero, also used 3B+) that connects to my
Synology NAS via WiFi.The entire Weewx folder lives on the NAS so that the
data base and regularly generated files all live on storage that is not so
prone to wearing out.
I also use systemd to make sure that the network is
(Note: Probably off topic but weewx related)
I am running weewx (on a raspberry Pi Zero) and I'm seeing something that I
can't explain
Using my HP1000 driver to access my WS1001, weewx and the driver seem to be
doing what they should in that the driver is reading the old records that
it
Thanks everyone.
Some responses:
- the log I showed in the OP was from journalctl - thanks for the
suggestion though
- I didn't think that weewx as doing something special during the
'genStartupRecords' step but I just wanted to check
- I did Google those messages and (as with the replies here)
I'm not sure what procedure you are talking about with the 'historic'
values.
As far as the HP1000 driver is concerned, it looks at the last date in the
weewx database and then queries the weather station for any records it has
for after that date. Therefore it typically only downloads
I must be missing something but I can't see any error messages in the logs
posted so far. Without those it i shard to guess what is going on.
As far as I am aware, I don't have any try-except blocks that capture and
ignore everything and if an error occurs in the HP1000 driver that I don't
You need to make sure that the weewx bin directory is in the PYTHONPATH.
I've just run weewx from python, but something like
$ PYTHONPATH=/home/weewx/bin thonny..
- Use whatever the location of weewx is and whatever command you use to
invoke thonny.
Susan
On Friday, December 21, 2018 at
Sorry everyone but I've only just seen this thread (it would have helped if
the title referenced the HP1000 driver).
As for the unpacking error - that would indicate that the packet from the
HP1000 itself has altered, especially if it was working and then stopped.
Has something been updated -
Also which version of weewx are you running?
I've not tested the HP1000 driver with the latest version (I know, I know).
Susan
--
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,
It comes down to the source of the failure you want to monitor.
Using systemd will let you restart weewx if it stops running but will not
detect it looping or otherwise 'working' (as seen by the OS). It also won't
detect a OS crash or power down.
if you just want the appearance of a file or
I'm not sure what this means but if it works then great.
On Monday, April 8, 2019 at 8:59:13 PM UTC+10, Ron wrote:
>
> Oh, in my repo I also changed the formatting of the installation steps in
> the README file. Githubs markdown was smushing them all onto a single line
> and eating the portions
I've updated the files in github with the error fix(es) that Ron suggested.
I have *NOT* tested this with the latest version of Weewx nor with the
Python 3 version - that work is yet to come.
Susan
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
AAGGHH - this is what happens when you try to refactor your code and forget
about variable scoping.
The 'network_retry_count' variable IS set (with the line you added) in line
493 which is right at the start of the 'getLoopPackets' function.
The next part of the process is to use the
46 matches
Mail list logo
