I have recently updated the weewx wiki with some mods to scripts. I am now
using a 180 instead of the 280...it failed on me and I had a 180 lying around.
I also now have UV operational and working on a responsive skin.
The wiki has a link to my station
Use any scripts as needed.
Neville
--
Y
The URLs you have posted show values of 0.06 or 0.07, but your narrative
talks about 0.6 and 0.7. I assume the former is correct and the latter is
just a typo?
The value for dailyrainin comes from field dayRain in the current record,
which, in turn, is pulled off the Vantage weather station. This
Ok, I found the offending line in the template and it's this one here:
set $hour_rain_max = $hour.rain.max.raw * $rain_mult
It's now populating the gauges with data, but for some strange reason the
temperature and aparent temp gauges are cycling from some -5000 number up
to the correct number o
Tried running weewx directly and found out some interesting things:
LOOP: 2017-01-20 08:53:54 EST (1484920434) altf: 797.8077, altimeter:
29.865984751, altm: 243.1718, appTemp: None, barometer: 29.856421862,
cloudbase: 6661.05106707, dailyrainin: 0.627, dateTime: 1484920434.0,
dewpoint: 43.92
Using the latest rtl_433 and the latest sdr.py my rain totals match the
console. And yes the 5n1 is ouput from rtl_433 is now json
--
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,
Ok, I think I solved the rain problem. I supplied weewx with a value for
"rain" from my weather station. So rather than just supplying the rainRate
value from my station, I'm feeding it both, and now the
gauges-data.txt.tmpl file is working without any edits. Now all I have to
do is solve w
Yes, 0.6 and 0.7 were typos, 0.06 and 0.07 are the intended values.
Thanks for the pointers -- I think I understand and am sorted now. Since
dayRain is provided by Vantage console in the loop packet but not the
archive packet, weewx uses the console's straight value for the former and
generates
Looks like I have also solved the issue with the wonky scale on the temp
gauges. I read that the max and min for the gauges is set by the daily max
and min. I deleted my weewx database and started fresh, I let weewx
calculate the rainrate and just supplied the rain value to weewx from my
weat
Ok, just one more picky thing to work out and that is why the aparent
temperature isn't working (shows -20 ). I'm wondering if there is another
variable I need to input into weewx to make that happen?
On Thursday, 19 January 2017 08:44:51 UTC-5, Robert Mantel wrote:
>
> I have a brand new Raspb
a lot of thanks
I will do !
El 20 ene. 2017 1:25 PM, "Neville Davis"
escribió:
> I have recently updated the weewx wiki with some mods to scripts. I am now
> using a 180 instead of the 280...it failed on me and I had a 180 lying
> around. I also now have UV operational and working on a responsiv
Ok, a few things to digest.
Ok, I found the offending line in the template and it's this one here:
>
> set $hour_rain_max = $hour.rain.max.raw * $rain_mult
>
That is interesting, $hour.rain.max.raw gives you the highest rainfall in
an archive period over the last hour, but then the variable in w
Would weewx support rsync to 'two' remote servers ?
I'm going to be moving my site to a different ISP and have the new server
online but haven't repointed DNS at it yet. If I set up multiple blocks in
weewx ala the [RSYNC] one, just with a different name ala [RSYNC2] with the
appropriate remot
I run mutliple RSYNC reports, albeit to the same server but different with
different HTML_ROOT settings. Can't see why it wont work, its just another
report with its own settings.
Gary
On Saturday, 21 January 2017 11:15:11 UTC+10, vince wrote:
>
> Would weewx support rsync to 'two' remote serve
I can confirm it works. I had to make a [[RSYNC2]] block as I originally
guessed. Cool.
On Friday, January 20, 2017 at 5:17:51 PM UTC-8, gjr80 wrote:
>
> I run mutliple RSYNC reports, albeit to the same server but different with
> different HTML_ROOT settings. Can't see why it wont work, its
I have the ss gauges working fine with WeeWx but they display in °C.
http://suiattle.net/DinkinsBayouWeather/ss/index.html
I've changed the units in /skins/ss/skin.conf to use US units but it
doesn't seem to effect the change. What am I missing in how to accomplish
this?
RPi 3
WeeWx 3.6.2
--
I look at your site it says your station has been offline for some 37 odd
hours, in other words your gauge-data.txt is 37 odd hours old
("date":"2017.01.19 07:50")
What's in your logs? Is gauge-data.txt being generated without error and if
it is being generated (if applicable) is it being uplo
Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file
/gauge-data.txt
10 minutes ago.
I can't see any errors related to that in the log.
On Friday, January 20, 2017 at 9:36:40 PM UTC-5, gjr80 wrote:
>
> I look at your site it says your station has been offline for some 37 odd
> hou
Interesting, when I look at your gauge-data.txt at
http://suiattle.net/DinkinsBayouWeather/ss/gauge-data.txt I see a file
timestamped on 19 January
Gary
On Saturday, 21 January 2017 12:56:32 UTC+10, Dan'l B wrote:
>
> Jan 20 21:46:10 raspberrypi weewx[671]: ftpupload: Uploaded file
> /gauge-da
Just deleted gauge-data.txt on the Pi and on the server and it reloads with
the same issue.
On Friday, January 20, 2017 at 9:59:40 PM UTC-5, gjr80 wrote:
>
> Interesting, when I look at your gauge-data.txt at
> http://suiattle.net/DinkinsBayouWeather/ss/gauge-data.txt I see a file
> timestamped
Well, 4 different browsers across 3 different machiens and I am seeing the
same gauge-data.txt with the same 19 January timestamp. What do you see
when you look at gauge-data.txt in your browser?
On Saturday, 21 January 2017 13:41:20 UTC+10, Dan'l B wrote:
>
> Just deleted gauge-data.txt on the
20 matches
Mail list logo