OK, found 4.0.0b9, yes indeed altimeter was before pressure. Plus when you
look back at the initial log extract provided you can see the evidence:
Jan 4 13:48:41 raspberrypi weewx[11987] INFO weewx.engine: Initializing
weewx version 4.0.0b9
Jan 4 13:48:41 raspberrypi weewx[11987] INFO
> Once I sort this possible discrepancy, I'd like to pick your brain on adding
> the Station Volts.
I added it at head. Station volts will now show up as supplyVoltage.
> On Jan 4, 2021, at 7:44 PM, John Kline wrote:
>
>
> The IP100 resets the day’s rain total at midnight (according to
Ah, didn't notice that. the other thing is you appear to be running a late
beta of a version about four versions ago. Plus there has been quite a few
changes to StdWXCalculate over the last few releases. You may find that the
issue has been resolved (deliberately or unintentionally) in one of
Updated and working OK so far.
Thanks
https://weather.ubeaut.work/
On Tuesday, 5 January 2021 at 10:28:30 UTC+11 tke...@gmail.com wrote:
> This release fixes a bug in V4.2 that caused average values to be calculated
> incorrectly if the archive interval changes.
>
>
> 4.3.0 01/04/2020
>
>
The issue is that it's looping over the calculations in that order in the
wxservices.py source code, and not the order from the weewx.conf.
I had to edit the order in the wxservices.py code in order to get things to
work right.
I did add it as an issue in the github repository.
On Monday,
Yes, pressure needs to be listed before the other pressures, order matters
in this case. I thought of that but the wee_debug output you provided in
the other thread showed pressure was first so I did not bother. No matter,
I guess it's fixed now.
Gary
On Tuesday, 5 January 2021 at 13:38:15
OK, so there you go, you should find gauge-data.txt appearing in
/var/www/html/weewx/realtime.
Jan 5 01:01:44 metfm weewx[31863] DEBUG weewx.engine: Loading service
> user.rtgd.RealtimeGaugeData
> Jan 5 01:01:44 metfm weewx[31863] DEBUG weewx.manager: Daily summary
> version is 2
> Jan 5
The IP100 resets the day’s rain total at midnight (according to it’s clock).
It doesn’t really matter to the driver when that happens. The driver is simply
looking for a positive increment in day_rain_total. On a negative increment
(e.g., reset), the driver just saves the last value and
I'm fairly sure that's correct as it still reports the pressure when the
battery to the outdoor sensor runs down.
On Mon, Jan 4, 2021 at 6:33 PM wrote:
> I want to make sure the pressure sensor for the Accurite 02032C is in the
> indoor console and not in the 5-1 sensor that is placed on a pole
Thanks for the guidance John! I was anticipating to simply have a day
with a clean run, starting at midnight. I should have this info tomorrow.
I assume the loop will recognize my local timezone to reset to zero at
midnight, recognizing the db is being recorded on GMT?
Once I sort this
Think I figured it out.
Calculating the altimeter depends on pressure being calculated, but the
list of calculations had pressure in alphabetical order.
I moved pressure in the calculations section before altimeter and my
problem appears to be solved.
wxservices.py line 46
[[Calculations]]
I think I figured it out. I also have 2 threads on here about this and I
apologize for that. The other one I thought I had deleted, but I posted
the solution there.
On Monday, January 4, 2021 at 7:21:39 PM UTC-8 gjr80 wrote:
> You are correct in that the missing altimeter is your problem,
You don’t to delete records. There isn’t really much to the rain calculation.
For all rain that occurred while WeeWX is up and running, the day_rain_total
will increment, the driver will calculate the delta and add it to the loop
record as ‘rain’. For the discrepancy to occur, 0.09 inches
Thanks for the quick response John!
I am running your version of the IP100 for weewx 4 - version 0.5
I did restart the weewx today -- had some network issues, compliments of
Comcast. However, I've witnessed discrepancies between the IP100 Console
and weewx for several days -- just finally
Did the attached file get removed by the google groups filters? or did you
not attach? Thanks
On Sunday, January 3, 2021 at 1:10:18 PM UTC-6 stelli...@gmail.com wrote:
> Solved it on my own. If others are interested, here is what I did:
>
>1. Copying the sensors.inc file from the Seasons
Think I figured it out.
Calculating the altimeter depends on pressure being calculated, but the
list of calculations had pressure in alphabetical order.
I moved pressure in the calculations section before altimeter and my
problem appears to be solved.
wxservices.py line 46
You are correct in that the missing altimeter is your problem, fix that and
CWOP will be fine. As long as WeeWX has one of the three pressures it can
calculate the other two. Davis stations provide barometer so WeeWX should
be calculating pressure and altimeter.
Maybe the contents of your
I'm thinking it has something to do with wxservices.py.
At around line 558, there's this code for calculating 'altimeter'. I do not
have a value for 'pressure' in the record. I have 'barometer', which I'm
assuming is '
Sensor Pressure' from reading some of the comments in the python code.
Station volts is not in the default map. It wouldn’t be hard to add.
I did the IP100 port to WeeWX 4 and fixed bugs in the driver (and bumped the
version to 0.5 in my fork). I’m presuming you are running it.
Although I’m not currently running the driver, I did run it for almost two
years and
I want to make sure the pressure sensor for the Accurite 02032C is in
the indoor console and not in the 5-1 sensor that is placed on a pole
outdoors.
Thanks,
Chris Maness
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from
I recently stood up a Raspberry Pi 4 running weewx 4.2.0 with the IP-100
v0.5 extension. It appears the IP-100 Console data does not match the data
presented via weewx (using the out-of-box index.html, which is using the
SeasonsSkin) -- particularly, the Rain and Rain Rate. I've shared
That's the string that restx.py is setting it to if the altimeter value is
None before it feeds it to CWOP.
I had been using some VERY old code prior to updating to run on the
raspberry pi, so I'm not surprised there is something broken.
Just debugging my way through the python till I figure
That b makes me think it's a string/byte python2 vs python 3 issue. I have
no evidence to back that up...
On Mon, Jan 4, 2021 at 4:57 PM Brent Dowell wrote:
> I apologize for the duplicate messages. This was the first one I posted,
> and tried to delete earlier. There's another post I made
I apologize for the duplicate messages. This was the first one I posted,
and tried to delete earlier. There's another post I made that has more
detailed info.
On Monday, January 4, 2021 at 4:56:28 PM UTC-8 Brent Dowell wrote:
> It's not uploading the barometric pressure.
>
>
>
It's not uploading the barometric pressure.
CW8738>APRS,TCPXX*,qAX,CWOP-4:@032150z3949.85N/11938.56W_315/009g014t050r000p000P000
*b.*h46.weewx-4.0.0b9-Vantage
Looking at the code, it's supposed to calculate the 'altimeter' value from
'barometer'. However it's not doing that. Altimeter
Everything looks normal to me. The log shows a post to CW8738:
Jan 4 13:50:18 raspberrypi weewx[11987] INFO weewx.restx: CWOP: Published
record 2021-01-04 13:50:00 PST (1609797000)
After that, you did a keyboard interrupt, but the log stops before the next
reporting cycle.
Taking a look at
Also tried making sure that the barometer on the vantage vue console was
properly calibrated.
The value for altimeter continues to be 'None'. This used to work when I
ran it on a box I had ubuntu loaded on.
On Monday, January 4, 2021 at 3:21:20 PM UTC-8 Brent Dowell wrote:
> Well, I think
This release fixes a bug in V4.2 that caused average values to be
calculated incorrectly if the archive interval changes.
4.3.0 01/04/2020
Version 4.2.0 had a bug, which caused the sums in the daily summary to be
incorrectly calculated. This version includes a patch to fix the problem. It
runs
Well, I think I found something in restx.py.
For CWOP, there is a line that says
_baro = record.get('altimeter')
Well, looking at my loop data there is no altimeter field in it.
I do see in the startup that it says
weewx.wxservices: The following values will be calculated:
Bizarre, 8 am still confident there is something in your Seasons
index.html.tmpl that is causing an error hence it’s not generated. Can you
post your copy of Seasons index.html.tmpl? Maybe something will stand out.
Gary
On Tuesday, 5 January 2021 at 07:56:51 UTC+10 blu...@gmail.com wrote:
> I
On 04.01.2021 22:50, vince wrote:
So you're saying:
* periodically loses connection to the station
*/rather rarely - but at times (1-5 times in a year, usually due
to maintenance - see below)/**/
/**/it also technically happens during a reboot or a short time
shut down of the
A couple months ago I moved my weather station to run on a Raspberry pi,
and things have been running smoothly with the exception of the data that
gets uploaded to CWOP.
I upload data to cwop, wunderground, pwsweather, and my own weather site.
The only one missing the data is cwop.
I'm
I just double checked /etc/weewx/weewx.conf and wee_debug and both are
showing debug = 1 and [StdReport] log_failure = True.
Did another sudo /etc/init.d/weewx restart, still no DEBUG entries in
/var/log/messages.
index.html in /var/www/html/weewx has the 1 January timestamp, but all the
graph
A couple months ago I moved my weather station to run on a Raspberry pi,
and things have been running smoothly with the exception of the data that
gets uploaded to CWOP.
I upload data to cwop, wunderground, pwsweather, and my own weather site.
The only one missing the data is cwop.
I'm
In the dark mode the graphic for the moon flips and shows the moon phase
icon as a different phase
On Tuesday, 5 January 2021 at 08:38:01 UTC+11 vince wrote:
> See if you can do a simple .inc that writes out "my current theme is dark"
> or the like based on sessionStorage.getitem('theme')
So you're saying:
- periodically loses connection to the station
- yet when that happens it keeps writing out empty (your words) records
every archive period
- and when you press the button to reconnect to the station, you expect
weewx to grab any historical records ?
The first
Dears,
I'm a new user from Italy and very grateful for this beautiful software,
i'ts a few days that I'm connected my weather station to weather
underground website.
Currently I'm trying to modify some parameter to improve and customize the
result.
My set-up is:
A meteo station Lacrosse 2350
See if you can do a simple .inc that writes out "my current theme is dark"
or the like based on sessionStorage.getitem('theme') much like the
examples in changeTheme( )
belchertown_debug("Theme: sessionStorage.getItem('theme') is now: " +
sessionStorage.getItem('theme') );
Now how would you
not very long (except for the initial check - here are 51,330 records to
be covered)
- the story is (I meanwhile checked the data base content and the
syslog) that weewx continues writing (empty) records when it isn't
connected to the console.
I think that's the reason for not reading the
Thank you but unfortunately your log extract does not show the WeeWX
startup sequence which has important config info. Can you go back to your
log and copy/post the full WeeWX startup sequence.
Gary
On Tuesday, 5 January 2021 at 07:16:53 UTC+10 hobbyl...@gmail.com wrote:
> Jan 4 23:01:18
Jan 4 23:01:18 metfm weewx[25601] DEBUG weewx.drivers.fousb: live
synchronised
Jan 4 23:01:18 metfm weewx[25601] DEBUG weewx.drivers.fousb: packet
timestamp is 21:01:18
Jan 4 23:01:18 metfm weewx[25601] DEBUG weewx.drivers.fousb: estimated log
time 20:43:54 +/- 24s (20:43:30..20:44:18)
Jan
Hi,
Can you edit weewx.conf, set debug = 1, save weewx.conf and restart WeeWX .
Let WeeWX run for 15 minutes the take a copy of the log from when you
restarted WeeWX through until the 15 minutes elapsed. Post the log extract
here.
Gary
On Tuesday, 5 January 2021 at 06:33:42 UTC+10
I included a custom iframe into one of the index_hook_after_inc files.
This iframe is a link to some foreign site providing a picture. The link
includes a lot of parameters, one of them for light or dark background.
I have almost no knowledge about JavaScript. How can I adjust the link
How long does this check take when weewx restarts ? How much data do you
think is being missed ?
We'd have to see some logs. Set debug=1 and restart weewx and let it run
for a couple archive periods.
--
You received this message because you are subscribed to the Google Groups
Hmm, I’m still not convinced that the log is as it should be, log_failure
under [StdReport] is definitely = True? When reports are generated there
should be entries about skin.conf being found etc. Nonetheless, Seasons
seems to be generating the correct number of files. Can you check the
i installed the realtime gaquge-data extension and i try to upload every 60
secs.with these settings
# Options for extension 'Rtgd'
[RealtimeGaugeData]
date_format = %Y.%m.%d %H:%M
stale_age = 60
rtgd_path = /var/www/html/weewx/realtime
scroller_source =
I'm running weewx on Raspberry Pi with my Klimalogg Pro (KLP) and the KL
extension/skin.
At the first start it reads all the existing data records from the
Klimalogg Pro (52,000+) and stores them in the database.
Great!
Now I observed that when the connection for some reason gets lost - or
hi
happy new year at all
I had already this issue, now I used a disk ssd for my RPi3b.
bye
Patrick
Le 04/01/2021 à 20:18, Xant a écrit :
I recently also had a corrupted SD card. Tried many alternatives to
recover data, including trying to mount at a Linux machine (at no
prevail).
The
Looks like the Route53 prices came down a lot over the years, so I might
take another look at it. I'm paying a buck/month for Google hosting my
DNS and I like the feature set a lot, but there's something to be said for
being all-in on one vendor since AWS's APIs are pretty solid.
I guess I'd
I recently also had a corrupted SD card. Tried many alternatives to recover
data, including trying to mount at a Linux machine (at no prevail).
The only (Windows) solution that actually worked was, where I was able to
read and retrieve data, was the freeware "DiskInternals Linux Reader":
I use a three foot USB extension cord on the GW1000. I had one instance
where the phone-charger-type power supply generated enough trash to hamper
the GW1000 reception.
On Monday, January 4, 2021 at 11:07:30 AM UTC-6 lang@googlemail.com
wrote:
> Correct, for power only. You can use any
Thanks Tom, that is what I see and wanted to ensure the field should not be present in Loop 2. From: Tom KefferSent: Monday, January 4, 2021 10:59 AMTo: weewx-userSubject: Re: [weewx-user] Davis VP2 Console Logger Loop 1 vs Loop 2 The VantagePro2 and VantageVue offer two different types of LOOP
Correct, for power only. You can use any phone charger, USB hub etc. to
keep it running. Even plug it into a USB port of a Raspberry Pi if you
have one ...
A good idea will be to have the power source connected to a UPS, as well
as your weather computer :-), or have it connected to a power-bank
i was create a file in seasons skin (you can do also it in any skin)
with html variants .my settings.i name my file zwntana.html.tmp for example.
after that edit the skin.conf in [CheetahGenerator] section.
put this
[[Zwntana]]
[[[index]]]
template = zwntana.html.tmpl
Well I ordered a GW1000. Now I'm thinking about how to power it. The USB
connector is only used for power, right?
On Sun, Jan 3, 2021, 7:52 PM galfert wrote:
> I meant to say water leak not water lead sensor.
>
>
> On Sunday, January 3, 2021 at 10:51:34 PM UTC-5 galfert wrote:
>
>> The
Done. Nothing new in log.
Jan 4 07:59:09 corbett weewx[32526] INFO __main__: Initializing weewx
version 4.2.0
Jan 4 07:59:09 corbett weewx[32526] INFO __main__: Using Python 2.7.13
(default, Aug 22 2020, 10:03:02) #012[GCC 6.3.0 20170516]
Jan 4 07:59:09 corbett weewx[32526] INFO __main__:
The VantagePro2 and VantageVue offer two different types of LOOP packets,
dubbed "LOOP 1" and "LOOP 2".
The field txBatteryStatus is offered in LOOP 1 packets, but does not appear
at all in LOOP 2 packets. What are you seeing?
On Mon, Jan 4, 2021 at 6:45 AM gary@gmail.com
wrote:
> What is
The reason I switched from Fedora to CentOS was stability. Now that weewx
is running on Raspbian and that's stable, there's no reason not to use
Fedora for other things. I like the familiarity of the
RedHat/Fedora/CentOS distros, and the new "bells and whistles" introduced
in Fedora are
What is the difference between Loop1 and Loop 2 for WeeWX?
I ask because using Loop 2 alone my transmitter battery value is shown as
low where the value is Ok with Loop 1.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this
Thank you sir.
Chris Maness
On Sun, Jan 3, 2021 at 9:48 PM galfert wrote:
> It is the fault of all your neighbors with poorly calibrated stations. All
> you can do is reach out to all of your neighbors that you feel have done a
> poor job in calibrating their station. You all affect each
Hi Greg,
When 4.3.0 is released shortly you will find the [StdWXCalculate] stanza in
weewx.conf has been restructured and the previously undocumented settings
documented. ignore_zero_wind has been deprecated and replaced by a new
structure and config option force_null. ignore_zero_wind will
Go back and look at Fedora again if you haven't used it in the last few
years.It's better than it used to be and is worth a look.
On Sunday, January 3, 2021 at 4:56:37 PM UTC-6 WindnFog wrote:
> I suspect a lot of web hosting companies use CentOS. The outfit I was
> with in Florida sure
GNU nano 3.2
syslog
Here is the log
Jan 4 00:25:33 raspberrypi
I suspect you have an error in the generation of your Seasons index.html
file that is being masked by log_failure = False under [StdReport] in
weewx.conf. Try changing this to log_failure = True, (leave debug = 1)
restart WeeWX and see what appears in the log.
Gary
On Monday, 4 January 2021
- how do you get your stable .eu.com FQDN onto your website's ip address
?
I moved my service to Rout53 some time ago from DynDNS, this post shows how
I did that when I was hosting at
home
65 matches
Mail list logo
