[weewx-user] Re: yscale not working with barometer

[Paolo Benvenuto]

resolved: I had put

[[[yearbarometer]]]
barometer
yscale = 900, 1050, 10

I had to put:

[[[yearbarometer]]]
yscale = 900, 1050, 10
barometer

Il giorno sabato 11 marzo 2017 07:19:19 UTC+1, Paolo Benvenuto ha scritto:
>
> I want to set yscale for barometer plots so that it's a fixed range, so I 
> put something like
>
> barometer
>  yscale = 900, 1050, 10
>
> in the [ImageGenerator] section
>
> I expressed the values in millibar, which is the unit used in the plots.
>
> However, the automatic yscale is used: 
> http://weewx.qumran2.net/daybarometer.png
>
> What am I missing?
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] yscale not working with barometer

[Paolo Benvenuto]

I want to set yscale for barometer plots so that it's a fixed range, so I 
put something like

barometer
 yscale = 900, 1050, 10

in the [ImageGenerator] section

I expressed the values in millibar, which is the unit used in the plots.

However, the automatic yscale is 
used: http://weewx.qumran2.net/daybarometer.png

What am I missing?

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Question about the Realtime Gauge-Data Extension

[gjr80]

Hi,

The short answer to your question is no, nothing like that exists at the 
moment. If you have your web server (or process that wil use 
gauge-data.txt) on your weeWX machine then it is a simple matter for the 
generated file to be saved wherever you want, but if you need to transfer 
the file in near realtime to another machine then no that capability does 
not exist at the moment.

There is no technical reason why a loop based ftp or rsync service could 
not be written, I know that some have been tinkering with it. There are no 
weeWX issues raised on GitHub in this regard nor is there anything in the 
weeWX roadmap so I don't expect you will see such a service in the 
immediate future (3.7.0 has been soaking up most people's effort). I think 
it is fair to say there is some recogniton that some sort of loop based 
transfer mechanism is needed to support near realtime the likes of 
SteelSeries Gauges, Saratoga and Leuven templates and others but at the 
moment no effort has been put into creating a supported solution.

I expect Tom and Matthew may have well have further views on this.

Gary

On Wednesday, 8 March 2017 17:41:46 UTC+10, Alec Bennett wrote:
>
> I want to build a live weather widget for a website similar to what 
> Weather Underground displays on their pages:
>
>
> https://www.wunderground.com/personal-weather-station/dashboard?ID=KCAPETAL93
>
> Note the wind direction changing every few seconds, assuming my weather 
> station is behaving.
>
> I found the Realtime Gauge-Data Extension, and *think* it might enable 
> that sort of thing, except that I can't figure out how to 
> upload gauge-data.txt more often than the other files in my public_html 
> folder. To get true real time weather data it would need to be uploaded as 
> often as Weather Underground is updated in "rapidfire" mode.
>
> Is such a thing currently possible?
>
>
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: start problem

[gjr80]

Hi,

The reason is that you have set the path for your non-priveleged user but 
not for the privileged environment that sudo wil use. Try the following 
command:

$ sudo printenv

I'll bet the PATH environent variable doesn't include /home/weewx/bin. 
Simplest solution, just type the path (you'll need it for weewx.conf as 
well unless you are in /home/weewx) or run weewx as a non-priveleged user.

Gary

On Saturday, 11 March 2017 11:37:44 UTC+10, Joe Percival wrote:
>
> I have tried sudo weewxd weewx.conf but I get an error message saying 
> there there is no command weewxd.
> I installed using setup.py on ubuntu 16.04
> I have since upgraded to ubuntu 16.10 in an attempt to fix a bluetooth 
> keyboard problem (unsuccessfully).
> I put /home/weewx/bin on the PATH and have verified it using sudo $PATH.
> I temporarily changed ownership of the weewx directory so that I could run 
> the reconfiguration utility but have since changed ownership back to root.
>
> What might I have done wrong?
> Thanks,
> joe
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] start problem

[Joe Percival]

I have tried sudo weewxd weewx.conf but I get an error message saying there 
there is no command weewxd.
I installed using setup.py on ubuntu 16.04
I have since upgraded to ubuntu 16.10 in an attempt to fix a bluetooth 
keyboard problem (unsuccessfully).
I put /home/weewx/bin on the PATH and have verified it using sudo $PATH.
I temporarily changed ownership of the weewx directory so that I could run 
the reconfiguration utility but have since changed ownership back to root.

What might I have done wrong?
Thanks,
joe

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Keeping custom software calcs over update

[gjr80]

Hi,

Your problem is nothing to do with the WMR200 driver but rather the 
internal workings of the StdWXCalculate service. Since you have your hands 
in wxservices.py, have a look at the do_calculations() method (circa line 
174), you will see that the data packet provided to StdWXCalculate is 
converted to US units before the calculations are done and then converted 
back to the archive unit system before exiting. This is what is causing 
your problems. WeeWX does not know how to convert a temperature difference 
between F and C and vice versa so your extraTemp1 field is getting a double 
conversion as if it was an absolute (as opposed to differential) F value. 
There is little you can do without further hacking of wxservices.py, you 
could save a copy of extraTemp1 at the start of the method before the 
conversion and then overwrite the incorrect value in the packet as the last 
thing before the method exits but that is getting messy. You are really 
just making yourself more of an orphan.

Unfortunately this also means that the StdCalibrate suggestion I made will 
also not work as StdCalibrate does its stuff before StdWXCalculate so it 
will suffer from the exact same problem. If you were only using the 
differenc in a report I wuld suggest doing the calculation with some 
in-line python in a template but you appear to want to plot the data, that 
means it must be in the archive.

Gary

On Saturday, 11 March 2017 07:41:57 UTC+10, Karl Grant wrote:
>
> I might try that, in the meantime I patch wxservices.py with 
> def calc_extraTemp1(self, data, data_type):
> if 'inTemp' in data and 'outTemp' in data:
>try:
> data['extraTemp1']= round(data['inTemp'] - data['outTemp'
> ],1)
>except:
> pass
>
>
> I needed to use the try/except as it was crashing if there was 
> incorrect/null data in outTemp. This worked perfectly in 3.5, now I'm back 
> to having problems with F -> C conversion. My db is in MetricWX, 
> It appears that WeeWx is still working with degF, before conversion, 
>
> Data InTemp OutTemp CalcDifff 
> ActDiff InF OutF DiffF DiffFtoC 
> 2017-03-08 23:31:00  22.49.1 -4.5  22.40 9.10 
> -4.50 
> 13.3 72.32 48.38 23.94 -4.48 
> 2017-03-08 23:41:00  22.49.1 -4.5  22.40 9.10 
> -4.50 
> 13.3 72.32 48.38 23.94 -4.48 
> 2017-03-08 23:51:01  22.49.1 -4.5  22.40 9.10 
> -4.50 
> 13.3 72.32 48.38 23.94 -4.48 
> Is it anything to do with changes related to the wrm200 driver?
>
> On Wednesday, 8 March 2017 23:55:04 UTC, gjr80 wrote:
>>
>> Hi,
>>
>> One approach for a simple calculation like this could be to use the 
>> StdCalibrate service to set extraTemp1. In weewx.conf something 
>> like(untested):
>>
>> [StdCalibrate]
>> [[Corrections]]
>> extraTemp1 = inTemp - outTemp
>>
>> This will not be overwritten during upgrade and should achieve the same 
>> result. One thing to be aware of when using temperature differences is that 
>> weewx unit conversion will not work on a temperature difference. For 
>> example, if the driver for your station emits F and your database uses US 
>> units, but you try to display extraTemp1 in C it will be wrong. If you only 
>> display F you will be fine.
>>
>> Gary
>>
>>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Keeping custom software calcs over update

[Karl Grant]

I might try that, in the meantime I patch wxservices.py with 
def calc_extraTemp1(self, data, data_type):
if 'inTemp' in data and 'outTemp' in data:
   try:
data['extraTemp1']= round(data['inTemp'] - data['outTemp'],1
)
   except:
pass


I needed to use the try/except as it was crashing if there was 
incorrect/null data in outTemp. This worked perfectly in 3.5, now I'm back 
to having problems with F -> C conversion. My db is in MetricWX, 
It appears that WeeWx is still working with degF, before conversion, 

Data InTemp OutTemp CalcDifff 
ActDiff InF OutF DiffF DiffFtoC 
2017-03-08 23:31:00  22.49.1 -4.5  22.40 9.10 
-4.50 
13.3 72.32 48.38 23.94 -4.48 
2017-03-08 23:41:00  22.49.1 -4.5  22.40 9.10 
-4.50 
13.3 72.32 48.38 23.94 -4.48 
2017-03-08 23:51:01  22.49.1 -4.5  22.40 9.10 
-4.50 
13.3 72.32 48.38 23.94 -4.48 
Is it anything to do with changes related to the wrm200 driver?

On Wednesday, 8 March 2017 23:55:04 UTC, gjr80 wrote:
>
> Hi,
>
> One approach for a simple calculation like this could be to use the 
> StdCalibrate service to set extraTemp1. In weewx.conf something 
> like(untested):
>
> [StdCalibrate]
> [[Corrections]]
> extraTemp1 = inTemp - outTemp
>
> This will not be overwritten during upgrade and should achieve the same 
> result. One thing to be aware of when using temperature differences is that 
> weewx unit conversion will not work on a temperature difference. For 
> example, if the driver for your station emits F and your database uses US 
> units, but you try to display extraTemp1 in C it will be wrong. If you only 
> display F you will be fine.
>
> Gary
>
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] xTide - No Data

['Ralf Buck' via weewx-user]

Hello 

for forecast i install xTide and xTide-Data-nonfree.

but xtide dont find a city of germany. 

perhaps anyone have a idea, thx

pi@raspberrypi:~ $ tide -l "Hamburg"
-
XTide 2   Copyright (C) 1998 David Flater.

This software is provided under the terms of the GNU General Public
License, either version 3 of the License, or (at your option) any later
version.

Although the package as a whole is GPL, some individual source files
are public domain.  Consult their header comments for details.

NOT FOR NAVIGATION

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  The author
assumes no liability for damages arising from use of this program OR
of any 'harmonics data' that might be distributed with it.  For details, see
the verbose documentation at http://www.flaterco.com/xtide/.

This obnoxious message will go away permanently if you click "Don't show
this again" in the disclaimer window of the X windows client (xtide), or
if you create a file in your home directory called 
".disableXTidedisclaimer".
-

Indexing /usr/share/xtide/harmonics-initial.tcd...
Indexing /usr/share/xtide/harmonics-dwf-20100529-nonfree.tcd...
Indexing /usr/share/xtide/harmonics-dwf-20100529-free.tcd...
XTide Error:  STATION_NOT_FOUND
The specified station was not found in any harmonics file.

Error details:
Could not find: Hamburg



-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx uptime = 17234 -- how to fix the db?

[Michael Walker]

I removed the fake hardware clock from the problematic RPI.  I am not so 
sure about the other one.

Yes, installing an RTC would make sense, but there is no reason for me 
personally.

I have seen the problematic device waiting for a valid time while the DHCP 
server attempts to connect via Wifi, so, for the most part, that seems to 
be working.

Thanks

On Friday, March 10, 2017 at 9:32:39 AM UTC-5, mwall wrote:
>
> michael,
>
> there are a couple of issues at play here, but they all result from having 
> a bogus system time.
>
> 1) if the system time is bogus, then anything that weewx saves to the 
> database will have a bogus time stamp.  this results in current weather 
> data being saved with a timestamp of 1970, or a timestamp in the past that 
> conflicts with data already saved, or a timestamp in the future that then 
> conflicts when the clock is adjusted to the correct time.
>
> 2) the weewx uptime is reported incorrectly
>
> 3) fake hardware clock really screws things up, because it sets the time 
> to something close to ok, but still very much not ok.  this will result in 
> the same symptoms as (1).
>
> in weewx 3.4 there is a fix to prevent weewx from doing anything until the 
> system clock is at least somewhat sane.  this addresses many instances of 
> (1), but it does not deal with (3).
>
> in weewx 3.6 there is a fix that addresses (2).
>
> the best thing to do is to install a realtime clock on the pi.  in lieu of 
> that, at the very least you should remove fake hardware clock, otherwise 
> you risk polluting your database with bogus times.
>
> https://github.com/weewx/weewx/wiki/Raspberry-Pi
>
> m
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx uptime = 17234 -- how to fix the db?

[mwall]

michael,

there are a couple of issues at play here, but they all result from having 
a bogus system time.

1) if the system time is bogus, then anything that weewx saves to the 
database will have a bogus time stamp.  this results in current weather 
data being saved with a timestamp of 1970, or a timestamp in the past that 
conflicts with data already saved, or a timestamp in the future that then 
conflicts when the clock is adjusted to the correct time.

2) the weewx uptime is reported incorrectly

3) fake hardware clock really screws things up, because it sets the time to 
something close to ok, but still very much not ok.  this will result in the 
same symptoms as (1).

in weewx 3.4 there is a fix to prevent weewx from doing anything until the 
system clock is at least somewhat sane.  this addresses many instances of 
(1), but it does not deal with (3).

in weewx 3.6 there is a fix that addresses (2).

the best thing to do is to install a realtime clock on the pi.  in lieu of 
that, at the very least you should remove fake hardware clock, otherwise 
you risk polluting your database with bogus times.

https://github.com/weewx/weewx/wiki/Raspberry-Pi

m

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Images and colors

[Ruben Navarro Huedo]

Thank's Gary.
I was not using correct format !


El viernes, 10 de marzo de 2017, 11:30:18 (UTC+1), gjr80 escribió:
>
> Hi,
>
> Are you specifying your ImageGenerator colours in the correct format? The 
> available formats are listed in the comments at the start of the 
> [ImageGenerator] stanza in the Standard skin.conf (extract below):
>
> # Colors can be specified any of three ways:
> #   1. Notation 0xBBGGRR;
> #   2. Notation #RRGGBB; or
> #   3. Using an English name, such as 'yellow', or 'blue'.
> # So, 0xff, #ff, or 'blue' would all specify a pure blue color.
>
> Gary
>
>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: No data from station

[Ruben Navarro Huedo]

Hello wmr300 friends.
I want add a second wireless transmiter to my wmr300.
I will use :
One transmitter (Oregon *STC300)* using channel 1 for: Temp, Humid and Rain
Another transmitter (Also STC300) using channel 2 for: Wind
I need to read all this sensors like one only weather station.
WMR-300 console is reading it correctly (after adding channel 2), but 
wee_wx doesn't "read" wind information.
Can i do this with weewx?
How?

In another vein: Have we some more information about clearing console 
datalogger from weewx?

Thank's a lot.

El viernes, 24 de febrero de 2017, 18:48:16 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> This could be a GREAT new addon !
>
> El viernes, 24 de febrero de 2017, 1:18:26 (UTC+1), Cameron D escribió:
>>
>> I have the captures of the windows software clearing the log, but have 
>> not yet had time to analyse them.
>>
>> On Friday, 24 February 2017 01:55:18 UTC+10, mwall wrote:
>>>
>>>
>>> if the logger is full, then you will 'lose' data.  apparently the wmr300 
>>> logger must be cleared by punching buttons on the console.  if someone 
>>> knows of software that can clear the logger, please let us know so we can 
>>> implement this in weewx.
>>>
>>>
>>>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Te923 - TFA NEXUS - SolarRad - cloudheight

[Ioannis Zagkaretos]

Hi Mathias,
I am a new TFA Nexus owner and when I enter level pressure data e.g. 1003 
hPa, and altitude 0 m the estimated by Nexus local 
pressure is 996 hPa and the altitude is 61 meters. The real values are 1004 
hPa and 50 meters respectively.
What do you think about this? How is it affected the estimated by the 
barometer weather forecast?

Thanks in advance.

Ioannis


Τη Παρασκευή, 18 Μαρτίου 2016 - 7:09:28 μ.μ.  
UTC+2, ο χρήστης Matthias Jahn έγραψε:
>
> My weather station is a TFA NEXUS I read the data with the TE923 driver 
> with a Raspberry Pi. As database I use sqlite3.
> when you start ./bin/weewxd weewx.conf the data appear to be read into the 
> console.
>
> REC:2016-02-24 12:36:00 CET (1456313760) altimeter: None, appTemp: 
> None, 
> barometer: 29.9346492708, cloudbase: None, dateTime: 1456313760, dewpoint: 
> None, 
> ET: None, extraBatteryStatus1: None, extraBatteryStatus2: None, 
> extraBatteryStatus3: None, 
> extraBatteryStatus4: None, extraHumid1: None, extraHumid3: None, 
> extraHumid4: None, 
> extraLinkStatus1: None, extraLinkStatus2: None, extraLinkStatus3: None, 
> extraLinkStatus4: None, 
> extraTemp1: None, extraTemp2: None, extraTemp3: None, extraTemp4: None, 
> forecast: 6, heatindex: None, 
> humidex: None, inDewpoint: 44.5746948885, inHumidity: 66, inTemp: 55.76, 
> interval: 5, 
> link_1: 1, link_2: 1, link_3: 1, link_4: 1, link_5: 1, link_rain: 0, 
> link_uv: 1, 
> link_wind: 1, maxSolarRad: 380.920109219, outBatteryStatus: None, 
> outHumidity: None, 
> outLinkStatus: None, outTemp: None, pressure: None, rain: 0.0, 
> rainBatteryStatus: None, 
> rainLinkStatus: None, rainRate: 0, rainTotal: 14.34004, storm: 0, usUnits: 
> 1, UV: None, 
> uvBatteryStatus: None, uvLinkStatus: None, windBatteryStatus: None, 
> windchill: None, 
> windDir: None, windGust: None, windGustDir: None, windLinkStatus: None, 
> windrun: 64.7898389407, windSpeed: None
>
> but the data for maxSolar and cloud base do not appear in the database.
> thanks for the interest of my problems
>
> M.Jahn
>
> Am Freitag, 18. März 2016 17:47:49 UTC+1 schrieb Tom Keffer:
>>
>> Not a lot of information to go on...
>>
>> The default schema does not have a slot for cloud height. You would have 
>> to add it.
>>
>> It does have one for radiation. When you say you don't see it in the 
>> database, do you mean you used sqlite3 or the mysql utility and tried a 
>> query on it and it came up null? Or, something else?
>>
>> What kind of device?
>>
>> And, what do you mean by "integrate this data?" Do you mean you want to 
>> plot it? Show stats? Something else?
>>
>> -tk
>>
>>
>> On Fri, Mar 18, 2016 at 9:39 AM, Matthias Jahn  wrote:
>>
>>> Hi,
>>> when I start weewx manually, I see data from the Solar Radiation and cloud 
>>> height. These are not seen in the database and on the website, can 
>>> anybody help me further. How to integrate this data. Thanks in advance.
>>>
>>> -- 
>>> 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, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Images and colors

[gjr80]

Hi,

Are you specifying your ImageGenerator colours in the correct format? The 
available formats are listed in the comments at the start of the 
[ImageGenerator] stanza in the Standard skin.conf (extract below):

# Colors can be specified any of three ways:
#   1. Notation 0xBBGGRR;
#   2. Notation #RRGGBB; or
#   3. Using an English name, such as 'yellow', or 'blue'.
# So, 0xff, #ff, or 'blue' would all specify a pure blue color.

Gary

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Images and colors

[Ruben Navarro Huedo]

Hello.
I am trying configure my own images colours under [ImageGenerator].
My "problem" is imagegenerator is not showind correctly the colours.
Using the same colour code in HTML i have the correct colour, but is 
completly different using it in images.
Am i missing anythink?
I want use blue colours tones for day /night.
A lot of thank's

---
Ruben EA5BZ

-- 
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, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.