[weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Steve, good to see. The other good outcome is that I should be able to 
touch up those original instructions I provided.

Gary

On Sunday, 25 June 2017 12:20:50 UTC+10, Steve2Q wrote:
>
> Gary..It's working properly again WITH the charts. Apparently what was 
> happening is when I entered changes in the editor, they weren't being 
> uploaded properly to the web server even though it said the transfer was 
> completed. I think the editor was holding the unedited version in memory 
> and just uploaded that.
>
> Many thanks, Steve
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary..It's working properly again WITH the charts. Apparently what was 
happening is when I entered changes in the editor, they weren't being uploaded 
properly to the web server even though it said the transfer was completed. I 
think the editor was holding the unedited version in memory and just uploaded 
that.

Many thanks, Steve

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Good to see it is working Steve.

I do notice one thing: I use WindChill and HeatIndex on my main page. Using 
> the formulas, it either or both are not defined, Current Conditions show 
> "undefined" and nothing is plotted on the graphs. The gauge shows 32 
> degrees when the formulas are not met. Is there a way to link what the 
> gauge shows to the weewx calculation formula results? Perhaps have 
> "Undefined" displayed in the gauge window, with the indicator equal to the 
> outside temperature?
>

Unfortunately there is not much you can do. A similar issue arises if a 
sensor drops for some reason. The SteelSeries code is such that it takes 
the value for a given observation and tries to interpret it as a number, if 
it can then the number is displayed in the selected units, if it can't be 
converted to a number then 0 is displayed. There is no ability to display 
anything other than a number on the gauge LCD and the pointer just reflects 
what is on the LCD (or is it vice versa?). I guess you could say that I 
have contributed a little to the issue as rtgd.py will set a field to 0 in 
the applicable Metric units if the observation in non-numeric or undefined 
(or None in python parlance). So for temperature type fields that have a 
misisng or undefined value, 0C or 32F will be displayed. Why? I guess 
because I use Metric and I find that if a field is missing data displaying 
a 0 is better than a display of 32. I could probably make the units in such 
a case user selectable, so folks that display F will see 0F rather than 
32F. UInfortunately not much else that can be done short of modifying the 
SteelSeries code and I won't be embarking on that.

Maybe I should write up a "Real Time Gauges for Dummies" for the Wiki, 
> because my unfamiliarity with programming means I had to first learn the 
> basics like the best way(s) to edit different types of files to obtain my 
> goal (along with trying to have a little understanding of the programming 
> itself).
>

By all means, I will update the wiki on the realtime_gauge-data GitHub site 
and referece it on the weeWX wiki, but that will be a work in progress for 
a little while.

As a final thought a couple of things you might want to consider doing to 
fine tune your SteelSeries setup.

1. gauge-data.txt units. A default install of the realtime_gauge-data 
extension will result in gauge-data.txt containing Metric units. Whilst the 
SteelSeries Gauges page gives you the ability to change display units 
dynamically, anyone going to your page the first time will see the units 
used in gauge-data.txt. (as an aside the SteelSeries gauges stores a cookie 
that keeps your display units settings for subsequent page visits). Given 
you are in the US you might want to switch your gauge-data.txt units to US 
customary so that visitors will see US customary by default (I expect most 
of your visitors are US based). To do this you need to edit the 
[RealtimeGaugeData] [[Groups]] config options in weewx.conf. Just change 
the options to the units desired, the unit codes are the same as used in 
weeWX skins ie degree_C, degree_F etc. Be aware that the SteelSeries Gauges 
do not support all units that weeWX does (eg mmHg).

2. Mouseover plots. Given the changes made the mouseover plots are broken, 
I suspect a chnage is requried to gauges.js, the plots are still in 
Weather/ss on your web server but they are not being updated (refer point 3 
below). Try changing the following line (line 38) to read:

imgPathURL : '../ss/',// *** Change this to 
the relative path for your 'Trend' graph images

3. Disabling the [[SteelSeries]] skin was done as an easy way to prevent 
there being conflicting gauge-data.txt files on your web server. There are 
a few side issues to disabling the skin. One is that the ss/index.html file 
is no longer generated each report cycle, this means that things like weeWX 
version etc will never update on this page is you happen to upgrade weeWX. 
Another is that the mouseover plots for the gauges are not generated so 
your mouseover plots are empty. So you probably should re-enable the 
SteelSeries skin but disable couple of its features. I suggest you:

a. edit weewx.conf and remove the comments against the [[SteelSeries]] skin
b. edit skins/ss/skin.conf, locate [CheetahGenerator] and disable the 
generation of gauge-data.txt eg:

[CheetahGenerator]
encoding = html_entities
[[ToDate]]
[[[index]]]
template = index.html.tmpl
#[[[data]]]
#template = gauge-data.txt.tmpl

c. edit skins/ss/scripts/gauges.js and make the same changes to it that you 
made to gauges.js on your web server. We do this as once the skin is 
enabled again any restart of weeWX would see the gauges.js on your web 
server overwritten.
d. stop then start weeWX
e. check that it all still works!


Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To 

[weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary: It appears to be working fine now! I I made the last two changes you 
recommended, and that did the trick. I do notice one thing: I use WindChill 
and HeatIndex on my main page. Using the formulas, it either or both are 
not defined, Current Conditions show "undefined" and nothing is plotted on 
the graphs. The gauge shows 32 degrees when the formulas are not met. Is 
there a way to link what the gauge shows to the weewx calculation formula 
results? Perhaps have "Undefined" displayed in the gauge window, with the 
indicator equal to the outside temperature?

I certainly appreciate all your patience in helping a NOOB. Maybe I should 
write up a "Real Time Gauges for Dummies" for the Wiki, because my 
unfamiliarity with programming means I had to first learn the basics like 
the best way(s) to edit different types of files to obtain my goal (along 
with trying to have a little understanding of the programming itself).

Anyway, kudos to you, Tom, Matthew, and the many others who developed Weewx 
and lend all of this support.o

Steve

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Just noticed in gauges.js at about line 37 it shows

weatherProgram : 0,  //Set 0=Cumulus, 1=Weather 
Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

not sure how this ever worked as it needs to be 6 for it to work with weeWX. 
You will need to change it to (note no quotes)

weatherProgram : 6,  //Set 0=Cumulus, 1=Weather 
Display, 2=VWS, 3=WeatherCat, 4=Meteobridge, 5=WView, 6=WeeWX

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Steve,

The issue is that the SteelSeries Gauges cannot find your gauge-data.txt file. 
When I point my browser at 
http://photokinetics.org/Weather/ss/scripts/gauges.js I see the following:

realTimeUrlWeewx   : 'photokinetics.org/Weather/gauges/gauge-data.txt', 
//*** WeeWX Users: Change to your location of the gauge data file ***

which is different to what you posted. I think you want 

realTimeUrlWeewx   : '../gauges/gauge-data.txt', //*** WeeWX Users: 
Change to your location of the gauge data file ***

Interestingly enough your change to display the windrose took, but the one 
above did not. Try making the change again.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Steve,

Missed that duplicate, didn't see the woods for the trees. No need to look 
in any weeWX logs, I can see that everything is working as it should as 
there is a gauge-data.txt appearing in your Weather/gauges directory on 
your web server and it is current and updating. Since gauge-data.txt is in 
a different location to where the previous ss skin generated gauge-data.txt, 
you will need to make a change in one of the SteelSeries scripts so that 
the SteelSeries Gauges know where to find gauge-data.txt.

You need to edit the file gauges.js on your web server, you should find it 
in the Weather/ss/scripts directory. The following line (about line 68):

realTimeURL_weewx : 'gauge-data.txt', //*** WeeWX Users: Change to your 
location of the gauge data file ***

needs to be changed to

realTimeURL_weewx : '../gauges/gauge-data.txt', //*** WeeWX Users: Change 
to your location of the gauge data file ***

While you are at it, you should turn on display of the windrose since we 
now have windrose data in gauge-data.txt. Go down to line 323, it should be:

config.showRoseGauge = false;   // FIXME: add wind histogram to weewx 
SLE

and change it to

config.showRoseGauge = true;   // FIXME: add wind histogram to weewx SLE

Make the changes, save the file and try refreshing your gauges page. It 
should update on each loop packet and it should also show the windrose 
gauge.

Gary


On Friday, 23 June 2017 01:06:32 UTC+10, Steve2Q wrote:
>
> Gary...making progress!! I made the corrections you suggested and one I 
> found myself :); there was a duplicate line under [[Engine]] and when I 
> removed it it started. If you look at my site;  
> http://photokinetics.org/Weather/index.html and go to the Steel Gauges 
> button at the bottom you will see that the gauges don't "know" that weewx 
> is back online.
>
> At the present time I have this entry for [[SteelSeries]] in weewx.conf 
> under [StandardReport]. Perhaps it is not commented and/or indented 
> properly (I am slowly learning that is important)
>
> [[StandardReport]]
> # See the customizing guide to change the units, plot types and 
> line
> # colors, modify the fonts, display additional sensor data, and 
> other
> # customizations. Many of those changes can be made here by 
> overriding
> # parameters, or by modifying templates within the skin itself.
> 
> # The StandardReport uses the 'Standard' skin, which contains the
> # images, templates and plots for the report.
> skin = Standard
> 
> #[[SteelSeries]]
> #skin = ss
> #HTML_ROOT = public_html/ss
>
> There is also a /skins/ss directory from when I first added the gauges 
> which were updating at my 2 minute archive interval.
>
> That is where it is now. Are there any specific log files and/or should I 
> stop weewx, turn on debug and let it run?
>
> Also, a side question; /var/log is filled with various type of log, gz 
> files etc. Can all or some be deleted?
>
> I am in your debt...Steve
> 
>
>
>
>
>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary...making progress!! I made the corrections you suggested and one I 
found myself :); there was a duplicate line under [[Engine]] and when I 
removed it it started. If you look at my site;  
http://photokinetics.org/Weather/index.html and go to the Steel Gauges 
button at the bottom you will see that the gauges don't "know" that weewx 
is back online.

At the present time I have this entry for [[SteelSeries]] in weewx.conf 
under [StandardReport]. Perhaps it is not commented and/or indented 
properly (I am slowly learning that is important)

[[StandardReport]]
# See the customizing guide to change the units, plot types and line
# colors, modify the fonts, display additional sensor data, and 
other
# customizations. Many of those changes can be made here by 
overriding
# parameters, or by modifying templates within the skin itself.

# The StandardReport uses the 'Standard' skin, which contains the
# images, templates and plots for the report.
skin = Standard

#[[SteelSeries]]
#skin = ss
#HTML_ROOT = public_html/ss

There is also a /skins/ss directory from when I first added the gauges 
which were updating at my 2 minute archive interval.

That is where it is now. Are there any specific log files and/or should I 
stop weewx, turn on debug and let it run?

Also, a side question; /var/log is filled with various type of log, gz 
files etc. Can all or some be deleted?

I am in your debt...Steve



   
   

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Steve,

Comments below.

Gary

On Thursday, 22 June 2017 11:37:20 UTC+10, Steve2Q wrote:
>
> Gary,  I have been plodding along but no joy. What is happening is after I 
> make the changes to weewx.conf, post_gauge-data.php, etc., Weewx wont even 
> start, so I don't have a syslog file for you to look at.
>

Looking at the weewx.conf you posted you have two [RealtimeGaugeData] 
stanzas:

# This is the stanza for Real Time Guage Data

[RealtimeGaugeData]
[RealtimeGaugeData]

This will certainly cause weeWX to hiccup very early in the startup, though 
it should give some output to log. I put the same config on a test system 
and received the following in the log:

Jun 22 15:24:17 jessie114 weewx[2288]: engine: Initializing weewx version 
3.7.1
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Using Python 2.7.9 (default, 
Jun 29 2016, 13:08:31) #012[GCC 4.9.2]
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Platform Linux-3.16.0-4-amd64
-x86_64-with-debian-8.8
Jun 22 15:24:17 jessie114 weewx[2288]: engine: Locale is 'en_AU.UTF-8'
Jun 22 15:24:17 jessie114 weewx[2288]: engine: pid file is /var/run/weewx.
pid
Jun 22 15:24:17 jessie114 weewx[2279]: Starting weewx weather system: weewx.
Jun 22 15:24:17 jessie114 weewx[2292]: engine: Error while parsing 
configuration file /home/weewx/weewx.conf
Jun 22 15:24:17 jessie114 weewx[2292]: Reason: 'Duplicate section 
name at line 407.'

You need to remove the second [RealtimeGaugeData] heading. I had a look 
through your posted weewx.conf and nothing else jumps out at me, though the 
proof will be in the pudding so to speak. Once you have made that change 
stop then start weeWX and see how it goes. If weeWX still appears not to 
start, and nothing seems to be in the log, then run weeWX directly; 
 that should give 
you some output direct to screen and hopefully it will indicate what the 
problem is.

Before we worry about the HTTP POST side of things we need to make sure 
gauge-data.txt is being generated by weeWX, if it isn't we will likely end 
up chasing our tails trying to sort out HTTP POST.
 

> If you have the time, maybe you could look over some files and see if you 
> can find what I am doing wrong.
>
> This is my web server structure:
> root directory
>  |
>   -photokinetics.org
>|
>  -Weather
>   |
> - all my weather data in which I created a folder called gauges (which is 
> empty)
>
> On my Weewx machine (RaspberryPi) I used setup.py to do the initial 
> install of weewx.
>
>  First attachment is my post_gauge-data.php file.
>
> Next is my weewx.conf file renamed weewx.conf.modded.txt
>
> rtg.py is in /home/weewx/bin/user
>
> My web server has a folder called .php which contains folders labeled 7.0, 
> 5.6, 5.5, 5.4 and 5.3  Does this mean that my server has php installed and 
> configured?
>

Would seem to be a good sign, if I go to 
http://photokinetics.org/Weather/post_gauge-data.php in my browser I get 
the following error message displayed: 

Parse error: syntax error, unexpected '/' in /home/n2qlq/photokinetics.org/
Weather/post_gauge-data.php on line 28

That tells me 2 things. Firstly, PHP is installed because line 28 is trying 
to be executed (rather than 'displayed' which is what would happen if PHP 
was not enabled). Secondly, there is an error at line 28 in the file. 
Looking at the post_gauge-data.php you posted line 28 is:

$json_file = /photokinetics.org/Weather/gauges/gauge-data.txt

whereas the original was:

$json_file = "data/gauge-data.txt";

so you need to put the quotes back in and end the line with a semi-colon. 
If I am reading your server directory structure correctly (some of those 
lines don't line up to well on a web page) you probably want $json_file to 
be set as follows:

$json_file = "gauges/gauge-data.txt";


> Anyway, Gary, I really appreciate your time in trying to help me out.
>
> Steve
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary,  I have been plodding along but no joy. What is happening is after I 
make the changes to weewx.conf, post_gauge-data.php, etc., Weewx wont even 
start, so I don't have a syslog file for you to look at.

If you have the time, maybe you could look over some files and see if you 
can find what I am doing wrong.

This is my web server structure:
root directory
 |
  -photokinetics.org
   |
 -Weather
  |
- all my weather data in which I created a folder called gauges (which is 
empty)

On my Weewx machine (RaspberryPi) I used setup.py to do the initial install 
of weewx.

 First attachment is my post_gauge-data.php file.

Next is my weewx.conf file renamed weewx.conf.modded.txt

rtg.py is in /home/weewx/bin/user

My web server has a folder called .php which contains folders labeled 7.0, 
5.6, 5.5, 5.4 and 5.3  Does this mean that my server has php installed and 
configured?

Anyway, Gary, I really appreciate your time in trying to help me out.

Steve





-- 
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 CONFIGURATION FILE
#
# Copyright (c) 2009-2015 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 1

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /home/weewx

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 3.6.2

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = "Valencia Pointe - Boynton Beach, FL"

# Latitude and longitude in decimal degrees
latitude = 26.514
longitude = -80.155

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 30, foot# Choose 'foot' or 'meter' for unit

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be used.
station_type = Ultimeter

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6
station_url = http://www.photokinetics.org/Weather
[CC3000]
# This section is for RainWise MarkIII weather stations and CC3000 logger.

# Serial port such as /dev/ttyS0, /dev/ttyUSB0, or /dev/cuaU0
port = /dev/ttyUSB0

# The station model, e.g., CC3000 or CC3000R
model = CC3000

# The driver to use:
driver = weewx.drivers.cc3000
[FineOffsetUSB]
# This section is for the Fine Offset series of weather stations.

# The station model, e.g., WH1080, WS1090, WS2080, WH3081
model = WS2080

# The polling mode can be PERIODIC or ADAPTIVE
polling_mode = PERIODIC

# How often to poll the station for data, in seconds
polling_interval = 60

# The pressure calibration offset, in hPa (millibars)
pressure_offset = 0

# The driver to use:
driver = weewx.drivers.fousb
[Simulator]
# This section for the weewx weather station simulator

# The time (in seconds) between LOOP packets.
loop_interval = 2.5

# The simulator mode can be either 'simulator' or 'generator'.
# Real-time simulator. Sleep between each LOOP packet.
mode = simulator
# Generator.  Emit LOOP packets as fast as possible (useful for testing).
#mode = generator

# The start time. If not specified, the default is to use the present time.
#start = 2011-01-01 00:00

# The driver to use:
driver = weewx.drivers.simulator
[TE923]
# This section is for the Hideki TE923 series of weather stations.

# The station model, e.g., 'Meade TE923W' or 'TFA Nexus'
model = TE923

# The driver to use:
driver = weewx.drivers.te923

# The default configuration associates the channel 1 sensor with outTemp
# and outHumidity.  To change this, or to associate other channels with
# specific columns in the database schema, use the following maps.
[[sensor_map]]
# Map the remote sensors to columns in the database schema.
outTemp = t_1
outHumidity = h_1

[weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

On Tuesday, 20 June 2017 10:01:55 UTC+10, Steve2Q wrote:
>
> Gary..." If you want to try to get the HTTP POST up and running let me 
> know and I will knock up some instructions.."
>
> That would be appreciated. While I understand some of the concepts and can 
> do minor modifications, I am in no way proficient in programming, but I am 
> great at following instructions. 
>

Have drafted some instructions but just need to run through them for 
completeness. Will be a tomorrow (for me) job.
 

> The post I referred to did not mention posting data to Wunderground, but I 
> think he figured out how the WU rapidfire windspeed/direction indicator 
> worked and then put the same on his website.
>
 
Correct, my mistake, I remember that now, he was imitating a WU like wind 
speed/dir display. (the data transfer for which is being done by a HTTP 
POST or GET I believe).

Gary
 

> Steve
>
>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary..." If you want to try to get the HTTP POST up and running let me know 
and I will knock up some instructions.."

That would be appreciated. While I understand some of the concepts and can 
do minor modifications, I am in no way proficient in programming, but I am 
great at following instructions. 

The post I referred to did not mention posting data to Wunderground, but I 
think he figured out how the WU rapidfire windspeed/direction indicator 
worked and then put the same on his website.

Steve


-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Steve,

I have been looking for references to HTTP POST, but have not yet found 
> anything. I am currently using FTP to upload to my website. Is it as simple 
> as just changing the FTP section in weewx.conf to say FTP POST? (probably 
> not! :))


HTTP POST is a method of communications over HTTP between a client and a 
server, in this case between your weeWX machine and the web server that 
hosts your site. It is similar to how weeWX sends data/rapid fire data to 
WU (well WU actually uses HTTP GET but the concept is the same). 
Practically, it entails storing a PHP script on your web server and each 
time the realtime gauge-data service generates the data for the 
gauge-data.txt file, the service contacts the script on your web server via 
a HTTP POST request and transfers the gauge-data.txt data to your web 
server and all being well the script then saves the data to gauge-data.txt 
on your web server.

I use HTTP POST to transfer gauge-data.txt on my LAN, I have not set it up 
with a hosted server though it should not be difficult. Provided your web 
server supports PHP (I think most hosted services do/can) the (broad) steps 
involved are (1) upload the PHP script to your web server (2) change a few 
settings in the [RealtimeGaugeData] section of weewx.conf (3) adjust the 
SteelSeries config (gauges.js)on your web server to pickup the new 
gauge-data.txt file. There may be some permission issues to deal with on 
your web server but they should not be too onerous.

Gary..I think I answered my own question. I didn't search deep enough 
> yesterday, but I found the info on some separate posts dealing with making 
> a Wunderground type windspeed/direction gauge. 


Hmm, interesting concept, post your data to WU so you can pull it down to 
display on your web page. If you want to try to get the HTTP POST up and 
running let me know and I will knock up some instructions, as I said above 
other than the standard install documentation the documentation is still a 
work in progress.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary..I think I answered my own question. I didn't search deep enough 
yesterday, but I found the info on some separate posts dealing with making a 
Wunderground type windspeed/direction gauge. 
I will start tomorrow. 
Steve 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary..I am making some notes for myself to follow based on the information you 
provided. I have been looking for references to HTTP POST, but have not yet 
found anything. I am currently using FTP to upload to my website. Is it as 
simple as just changing the FTP section in weewx.conf to say FTP POST? 
(probably not! :))

steve

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Gary..thank you very much for the very detailed reply. I will start working on 
it this week and keep you posted on my progress. 
Steve 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Hi Steve,

One of my earlier posts gave a link to the GitHub repo that contains the 
realtime gauge data extension. Here it is again: 
https://github.com/gjr80/weewx-realtime_gauge-data

1. I need a cookbook approach as I read thru the thread and can't quite get 
> my head around it. Do I just have to replace some of the Steel Gauge files, 
> or is it more complex?

The readme that displays on the GitHub link above has step by step 
instructions, hopefully they will do the job. If you are currently running 
the skin that generates gauge-data.txt you will need to disable that skin 
(comment it out in weewx.conf) or you will likely have have 2 services 
trying to write the same file. 

2. If I am successful will the new set of gauges have the wind rose?

Yes

Will the update be writing to my .sdb file (or any others) at the increased 
> rate?

No, the realtime gauge data extension intercepts loop data and generates 
(and writes) a gauge-data.txt file using a period defined by you (in 
weewx.conf). The database is not touched.

and like Nigel would only want the windspeed/direction to have such a quick 
> update

Not sure exactly what you want here. All fields, not just wind related 
ones, are updated from the latest data each time a gauge-data.txt file is 
generated, I presume this is acceptable. 

The realtime extension can generate a gauge-data.txt file on arrival of 
each loop packet or (less frequently if required). I am not familiar with 
your stations loop packets, but the info in the Hardware Guide 
 seems to indicate loop 
packets could occur as frequently as every 0.5 seconds. If you generate 
gauge-data.txt at that rate you could run into some issues because the 
extension may still be generating a file when the next loop packet comes in 
(how long it takes to generate will depend on you PC). You can certainly 
'slow down' the extension so that it generates, at best, every x seconds 
(using the min_interval option under [RealtimeGaugeData] in weewx.conf). 
Note that the documentation, other than the quick start instuctions, is 
still a work in progress. However, if you have a look at the comments at 
the start of the installed rtgd.py file you should see all the available 
options documented.

One limitation though, if the web server you are using is another PC or 
external and you were using FTP or RSYNC to transfer gauge-data.txt that 
approach is not supported with the realtime gauge data extension. The 
extension can save the file anywhere on the weeWX PC or use HTTP POST to 
send the file to a remote URL. HTTP POST should be easy enough to setup if 
needed, though it's not yet documented.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Steve2Q]

Hello: I presently have the Steel Gauges working with Weewx (v 3.6.2). They 
are currently updating at my archive interval of 2 minutes. I would like to 
have them work at my Ultimeter console loop interval of 2.5 seconds, and 
like Nigel would only want the windspeed/direction to have such a quick 
update: I have a few questions:

1. I need a cookbook approach as I read thru the thread and can't quite get 
my head around it. Do I just have to replace some of the Steel Gauge files, 
or is it more complex?

2. If I am successful will the new set of gauges have the wind rose?

3. Will the update be writing to my .sdb file (or any others) at the 
increased rate?

Thank you in advance,  Steve


-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

Hi Stefano,

Well done and nice site.
Interesting to see you also did a HAB.

Nigel

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[stefano siega]

Hi
I have integrated the update to 2.5 seconds for steelseries gauges using 
the same system that uses Mesowx.
I read from mysql database just the values ​​that make sense to be updated 
every two seconds. All other values ​​are read in the gauge-data.txt file

Here my page at 2.5 second update: 
http://www.flysohigh.net/weather/weewx/oseacco/steelseries/index

Here my station: http://www.flysohigh.net/meteo-val-resia/


Il giorno lunedì 2 gennaio 2017 14:12:43 UTC+1, Devonian ha scritto:
>
> I have just invested in a Davis Vantage Pro2, which replaced my WS2300 and 
> have installed Weewx 3.6.2 on Debian ver8 replacing my previous weewx ver 
> 2.7 for the WS2300.
>
> I would like to get the Steel Series gauges performing real time updates 
> at the Davis loop interval of 2.5 seconds.
> I have them installed OK, but it uses my current archive interval of 5 
> minutes - not quite real time!
>
> I tried mesowx, but can't get the data to display - the page appears, but 
> no graphs.  Data is getting saved into my MySQL 'raw' database at regular 
> 2.5 second loop intervals.  I'll continue trying to figure this one out.
>
> So, my thoughts turned to using the raw database for Steel Series and to 
> use raw data instead of archive data.
> I'm primarily interested in wind speed/direction, so if I could only get 
> that to update @ 2.5 seconds, I'd be happy with the others at 5 minutes.
>
> Anyone got any ideas on how to use this raw data instead of archive?
> Maybe there's a better/simpler way to achieve this 2.5 second update?
>
> Regards,
>
> Nigel.
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

Dropped the new file in place, stop/start weewx and it looks good to me 
Gary.
Online in the usual place if anyone is interested...

http://www.nthead.co.uk/ss/index.html

Nigel.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Unfortunately the issue will remain whilst the gauge-data.txt values are 
formatted to the likes of 1 decimal place. This issue also exists with 
other PWS software that produce a similarly formatted data file for use by 
the SteelSeries Weather Gauges. Changing the underlying units to the units 
normally used by the user will eliminate the issue for those units, but the 
issue will eventually recur if different units are selected for display 
(for example, your MPH values will now be accurate but someone observing 
your gauges in km/h will eventually see a similar small error, admittedly 
they won't have a console in front of them to highlight the discrepancy :) )

Gary

On Monday, 20 February 2017 04:06:11 UTC+10, tempus wrote:
>
> On Saturday, February 18, 2017 at 5:56:41 PM UTC-8, tempus wrote:
>>
>> On Saturday, February 18, 2017 at 5:43:42 PM UTC-8, gjr80 wrote:
>>>
>>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>>> need to sit down and work through the data. 
>>>
>>> Of course,  we could just disable F :) 
>>>
>>> Gary
>>>
>>>
>>> I will have a look at the code myself when I have time. 
>>
>> While you are looking, I noticed another issue. The gauge wind speed is 
>> 0.1 MPH less than shown on the Davis console.
>>
>> 1 MPH shows as 0.9 MPH
>> 2 MPH shows as 1.9 MPH
>> 3 MPH shows as 2.9 MPH
>> etc.
>>
>> Bob
>>
>
> This was found to be due to a loss of precision resulting from Rtgd 
> converting F to C and JavaScript then converting C back to F.  This and 
> other issues were fixed by specifying US units in weewx, like this:
>
> [RealtimeGaugeData]
> ...
>
> [[Groups]]
> group_pressure = inHg
> group_rain = inch
> group_rainrate = inch_per_hour
> group_speed = mile_per_hour
> group_distance = mile
> group_temperature = degree_F
> group_percent = percent
> group_uv = uv_index
> group_direction = degree_compass
>
> And by adding US 'StringFomats', like this:
>
> [[StringFormats]]
> degree_C = %.1f
> degree_F = %.1f
> degree_compass = %.0f
> hPa = %.1f
> inHg = %.3f
> inch = %.2f
> inch_per_hour = %.2f
> km_per_hour = %.0f
> km = %.1f
> knot = %.0f
> mbar = %.1f
> meter = %.0f
> meter_per_second = %.1f
> mile_per_hour = %.0f
> mile = %.1f
> mm = %.1f
> mm_per_hour = %.1f
> percent = %.0f
> uv_index = %.1f
> watt_per_meter_squared = %.0f
>
> Bob
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Option 3 was implemented in v0.2.3. No need to do anything with appTemp, 
rtgd taes care of it.

Gary

On Monday, 20 February 2017 06:05:34 UTC+10, tempus wrote:
>
> Your Option 3 below seems best to me.  Where is the best place to set 
> apptempL and apptempH both to the current appTemp value?
>
> Bob
>
> On Saturday, February 18, 2017 at 9:50:54 PM UTC-8, gjr80 wrote:
>>
>> I had a suspicion the issue was with apptemp and gauge autoscaling; since 
>> weeWX (by default) calculates appTemp and adds it to each loop/archive 
>> packet but does not natively archive appTemp, there are no stats 
>> available for appTemp, just the current value. I knew the SteelSeries 
>> gauges do not like null values in its data feed yet I foolishly left the 
>> day high and low apptemp fields in gauge-data.txt go to None (which 
>> results in null in the gauge-data.txt JSON format). This messed up the 
>> autoscaling that is triggerred when switching to F (I suspect that if you 
>> set rtgd to output F it would work fine but when you then change display to 
>> C it would exhibit similar bad behaviour). There are a few options:
>>
>> 1. customise weeWX to archive appTemp, ie follow the instructions at Adding 
>> a new observation type 
>>  in 
>> the Customization Guide. Note that there is no need to add a service as 
>> appTemp is already calaculated, the only real change is that you need to 
>> add appTemp to the db and set its units. Pretty easy stuff.
>>
>> 2. set apptempL and apptempH both to 0. The light red wedge on the 
>> apparent temp gauge that shows the appTemp day range would not show, we 
>> can't make up data so no problems there. The mouseover plot would show the 
>> day low and high to be 0 (or maybe 32 deending on source and display units) 
>> - that will be wrong but at least it is largely hidden from the user. The 
>> autoscaling could have some issues if you were in a very hot location where 
>> all your temps (outTemp, windchill, heatindex, humidex, dewpoint, appTemp) 
>> were relatively high; the apptempL and apptempH values may skew the 
>> autoscaling to the lower end. But the nonsense behaviour currently 
>> happening would not occur.
>>
>> 3. set apptempL and apptempH both to the current appTemp value. Again 
>> the light red wedge on the apparent temp gauge that shows the appTemp 
>> day range would not show. The mouseover plot would show the day low and 
>> high to be whatever the current appTemp value is - again that will be 
>> wrong but at least it is largely hidden from the user. The autoscaling 
>> would not be uspet (ie skewed) under any circumstances.
>>
>> 4. use weeWX-WD to record appTemp in a separate database. This has all 
>> the advantages of 1. without the need to chnage the weeWX database (which 
>> is not really an issue). I don't think this is a practical solution, its a 
>> bit like buying a Mack truck just to take a trip to the corner store for 
>> the paper each day (and finding your truck probably breaks down once a 
>> month!).
>>
>> At the moment I am leaning towards a hybrid; look for a day low/high 
>> appTemp, if they are available use them, otherwise set both to the 
>> current appTemp value. I could probably include a silent option in the 
>> rtgd config to specify a binding from where to get appTemp data which 
>> would default to wx_binding (the weeWX default binding) (I have my 
>> appTemp data in a separate datbase so this ability will almost certainly 
>> be included :) )
>>
>> Gary
>>
>> On Sunday, 19 February 2017 11:43:42 UTC+10, gjr80 wrote:
>>>
>>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>>> need to sit down and work through the data. 
>>>
>>> Of course,  we could just disable F :) 
>>>
>>> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Sorry if you aren't able load the test page. I have taken it down to fix an 
issue.

Bob

On Sunday, February 19, 2017 at 4:32:38 PM UTC-8, tempus wrote:
>
> This is a link to a page at a test-site if you want to see the gauges 
> updating at 3-second intervals.
>
> http://www.lablibrary.com/ss/
>
> There are no developer-credits or anything else other than gauges on that 
> page, because access is normally blocked at the firewall. I am just playing 
> around with ideas with the general intention to eventually embed that page 
> within another one at a public website.
>
> The Wind Rose still needs attention, but otherwise the gauges seem to be 
> working.
>
> Bob
>
> On Sunday, February 19, 2017 at 3:26:42 PM UTC-8, tempus wrote:
>>
>> I also just installed Gary's new rtgd-0.2.2 which fixed the Fahrenheit 
>> gauge-scaling issue. Thanks very much for finding and fixing that problem 
>> so promptly.
>>
>> Bob
>>
>> On Sunday, February 19, 2017 at 2:28:25 PM UTC-8, Devonian wrote:
>>>
>>> I have implemented Gary's latest updated file (no other changes to my 
>>> system).
>>> Seems OK now.
>>>
>>> I have no desire to display a forecast in the gauges.
>>> I use a link on my main weewx page to link to the UK Met Office for 
>>> 'professional' forecasting.
>>>
>>> Nigel.
>>>
>>>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

I also just installed Gary's new rtgd-0.2.2 which fixed the Fahrenheit 
gauge-scaling issue. Thanks very much for finding and fixing that problem 
so promptly.

Bob

On Sunday, February 19, 2017 at 2:28:25 PM UTC-8, Devonian wrote:
>
> I have implemented Gary's latest updated file (no other changes to my 
> system).
> Seems OK now.
>
> I have no desire to display a forecast in the gauges.
> I use a link on my main weewx page to link to the UK Met Office for 
> 'professional' forecasting.
>
> Nigel.
>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

I have implemented Gary's latest updated file (no other changes to my 
system).
Seems OK now.

I have no desire to display a forecast in the gauges.
I use a link on my main weewx page to link to the UK Met Office for 
'professional' forecasting.

Nigel.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Your Option 3 below seems best to me.  Where is the best place to set 
apptempL and apptempH both to the current appTemp value?

Bob

On Saturday, February 18, 2017 at 9:50:54 PM UTC-8, gjr80 wrote:
>
> I had a suspicion the issue was with apptemp and gauge autoscaling; since 
> weeWX (by default) calculates appTemp and adds it to each loop/archive 
> packet but does not natively archive appTemp, there are no stats 
> available for appTemp, just the current value. I knew the SteelSeries 
> gauges do not like null values in its data feed yet I foolishly left the 
> day high and low apptemp fields in gauge-data.txt go to None (which 
> results in null in the gauge-data.txt JSON format). This messed up the 
> autoscaling that is triggerred when switching to F (I suspect that if you 
> set rtgd to output F it would work fine but when you then change display to 
> C it would exhibit similar bad behaviour). There are a few options:
>
> 1. customise weeWX to archive appTemp, ie follow the instructions at Adding 
> a new observation type 
>  in 
> the Customization Guide. Note that there is no need to add a service as 
> appTemp is already calaculated, the only real change is that you need to 
> add appTemp to the db and set its units. Pretty easy stuff.
>
> 2. set apptempL and apptempH both to 0. The light red wedge on the 
> apparent temp gauge that shows the appTemp day range would not show, we 
> can't make up data so no problems there. The mouseover plot would show the 
> day low and high to be 0 (or maybe 32 deending on source and display units) 
> - that will be wrong but at least it is largely hidden from the user. The 
> autoscaling could have some issues if you were in a very hot location where 
> all your temps (outTemp, windchill, heatindex, humidex, dewpoint, appTemp) 
> were relatively high; the apptempL and apptempH values may skew the 
> autoscaling to the lower end. But the nonsense behaviour currently 
> happening would not occur.
>
> 3. set apptempL and apptempH both to the current appTemp value. Again the 
> light red wedge on the apparent temp gauge that shows the appTemp day 
> range would not show. The mouseover plot would show the day low and high to 
> be whatever the current appTemp value is - again that will be wrong but 
> at least it is largely hidden from the user. The autoscaling would not be 
> uspet (ie skewed) under any circumstances.
>
> 4. use weeWX-WD to record appTemp in a separate database. This has all 
> the advantages of 1. without the need to chnage the weeWX database (which 
> is not really an issue). I don't think this is a practical solution, its a 
> bit like buying a Mack truck just to take a trip to the corner store for 
> the paper each day (and finding your truck probably breaks down once a 
> month!).
>
> At the moment I am leaning towards a hybrid; look for a day low/high 
> appTemp, if they are available use them, otherwise set both to the 
> current appTemp value. I could probably include a silent option in the 
> rtgd config to specify a binding from where to get appTemp data which 
> would default to wx_binding (the weeWX default binding) (I have my appTemp 
> data in a separate datbase so this ability will almost certainly be 
> included :) )
>
> Gary
>
> On Sunday, 19 February 2017 11:43:42 UTC+10, gjr80 wrote:
>>
>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>> need to sit down and work through the data. 
>>
>> Of course,  we could just disable F :) 
>>
>> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Setting rtgd to output F doesn't correct the problem.

I have no personal interest in *windchill, heatindex, humidex,* or *appTemp* 
and want to set that gauge to always display *dewpoint*.

Bob

On Saturday, February 18, 2017 at 9:50:54 PM UTC-8, gjr80 wrote:
>
> I had a suspicion the issue was with apptemp and gauge autoscaling; since 
> weeWX (by default) calculates appTemp and adds it to each loop/archive 
> packet but does not natively archive appTemp, there are no stats 
> available for appTemp, just the current value. I knew the SteelSeries 
> gauges do not like null values in its data feed yet I foolishly left the 
> day high and low apptemp fields in gauge-data.txt go to None (which 
> results in null in the gauge-data.txt JSON format). This messed up the 
> autoscaling that is triggerred when switching to F (I suspect that if you 
> set rtgd to output F it would work fine but when you then change display to 
> C it would exhibit similar bad behaviour). There are a few options:
>
> 1. customise weeWX to archive appTemp, ie follow the instructions at Adding 
> a new observation type 
>  in 
> the Customization Guide. Note that there is no need to add a service as 
> appTemp is already calaculated, the only real change is that you need to 
> add appTemp to the db and set its units. Pretty easy stuff.
>
> 2. set apptempL and apptempH both to 0. The light red wedge on the 
> apparent temp gauge that shows the appTemp day range would not show, we 
> can't make up data so no problems there. The mouseover plot would show the 
> day low and high to be 0 (or maybe 32 deending on source and display units) 
> - that will be wrong but at least it is largely hidden from the user. The 
> autoscaling could have some issues if you were in a very hot location where 
> all your temps (outTemp, windchill, heatindex, humidex, dewpoint, appTemp) 
> were relatively high; the apptempL and apptempH values may skew the 
> autoscaling to the lower end. But the nonsense behaviour currently 
> happening would not occur.
>
> 3. set apptempL and apptempH both to the current appTemp value. Again the 
> light red wedge on the apparent temp gauge that shows the appTemp day 
> range would not show. The mouseover plot would show the day low and high to 
> be whatever the current appTemp value is - again that will be wrong but 
> at least it is largely hidden from the user. The autoscaling would not be 
> uspet (ie skewed) under any circumstances.
>
> 4. use weeWX-WD to record appTemp in a separate database. This has all 
> the advantages of 1. without the need to chnage the weeWX database (which 
> is not really an issue). I don't think this is a practical solution, its a 
> bit like buying a Mack truck just to take a trip to the corner store for 
> the paper each day (and finding your truck probably breaks down once a 
> month!).
>
> At the moment I am leaning towards a hybrid; look for a day low/high 
> appTemp, if they are available use them, otherwise set both to the 
> current appTemp value. I could probably include a silent option in the 
> rtgd config to specify a binding from where to get appTemp data which 
> would default to wx_binding (the weeWX default binding) (I have my appTemp 
> data in a separate datbase so this ability will almost certainly be 
> included :) )
>
> Gary
>
> On Sunday, 19 February 2017 11:43:42 UTC+10, gjr80 wrote:
>>
>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>> need to sit down and work through the data. 
>>
>> Of course,  we could just disable F :) 
>>
>> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Saturday, February 18, 2017 at 5:56:41 PM UTC-8, tempus wrote:
>
> On Saturday, February 18, 2017 at 5:43:42 PM UTC-8, gjr80 wrote:
>>
>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>> need to sit down and work through the data. 
>>
>> Of course,  we could just disable F :) 
>>
>> Gary
>>
>>
>> I will have a look at the code myself when I have time. 
>
> While you are looking, I noticed another issue. The gauge wind speed is 
> 0.1 MPH less than shown on the Davis console.
>
> 1 MPH shows as 0.9 MPH
> 2 MPH shows as 1.9 MPH
> 3 MPH shows as 2.9 MPH
> etc.
>
> Bob
>

This was found to be due to a loss of precision resulting from Rtgd 
converting F to C and JavaScript then converting C back to F.  This and 
other issues were fixed by specifying US units in weewx, like this:

[RealtimeGaugeData]
...

[[Groups]]
group_pressure = inHg
group_rain = inch
group_rainrate = inch_per_hour
group_speed = mile_per_hour
group_distance = mile
group_temperature = degree_F
group_percent = percent
group_uv = uv_index
group_direction = degree_compass

And by adding US 'StringFomats', like this:

[[StringFormats]]
degree_C = %.1f
degree_F = %.1f
degree_compass = %.0f
hPa = %.1f
inHg = %.3f
inch = %.2f
inch_per_hour = %.2f
km_per_hour = %.0f
km = %.1f
knot = %.0f
mbar = %.1f
meter = %.0f
meter_per_second = %.1f
mile_per_hour = %.0f
mile = %.1f
mm = %.1f
mm_per_hour = %.1f
percent = %.0f
uv_index = %.1f
watt_per_meter_squared = %.0f

Bob

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

I am sorry, I did not see this post with the flurry of activity on the 14th.

I appreciate the limitations of the Zambretti forecast, but I prefer it to 
'forecast not available'. I am not sure exactly what you mean by 'include 
webpage code that will display a professional forecast obtained via the 
Forecast extension or other means', when I said I would have a chat with 
Matthew I should have said that was in regards to getting the forecast 
extension to make available forecast text other than the Zambretti text. I 
am loathed to try to include other (internet based) lookups in rtgd, it 
already runs in its own thread generating output potentially every 2.5 
seconds. Pullling data from the internet or caching internet content is 
added time (through timeouts etc)/complexity that I don't think is 
warranted if we can get suitable info out of the forecast extension.

Gary

On Tuesday, 14 February 2017 02:49:48 UTC+10, tempus wrote:
>
> Has there been more progress on your new custom Service bound to the 
> NEW_LOOP_PACKET event?  It would be great to have even a 
> partially-functioning beta-version as a stop-gap solution.
>
>
> Zambretti forecast data doesn't seem important, because those forecasts 
> are so poor compared to forecasts readily available from multiple other 
> sources as to reflect poorly on the likely reliability of everything being 
> displayed.  Why not eliminate the Zambretti forecast and let users who want 
> a forecast above the gauges include webpage code that will display a 
> professional forecast obtained via the Forecast extension or other means?
>
> Bob
>
> On Monday, January 9, 2017 at 4:27:44 PM UTC-8, gjr80 wrote:
>>
>> Any chance you could use the NWS or WU current forecast for the 
>>> tickertape/scroller in place of the Zambretti?
>>>
>>
>> At the moment all I can do is pull the Zambretti forecast from the 
>> forecast database (provided the forecast extension is installed), 
>> unfortunately the WU and NWS forecast text is not saved in the forecast 
>> database. I have had the WU forecast text being pulled in through weewx-WD 
>> but that is something for the next version of weewx-WD and that is going to 
>> be weeks away (at least).
>>
>> I might have a chat with Matthew and see what he may be prepared to do, 
>> though I know he has a lot on at present.
>>
>> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

I had a suspicion the issue was with apptemp and gauge autoscaling; since 
weeWX (by default) calculates appTemp and adds it to each loop/archive 
packet but does not natively archive appTemp, there are no stats available 
for appTemp, just the current value. I knew the SteelSeries gauges do not 
like null values in its data feed yet I foolishly left the day high and low 
apptemp fields in gauge-data.txt go to None (which results in null in the 
gauge-data.txt JSON format). This messed up the autoscaling that is 
triggerred when switching to F (I suspect that if you set rtgd to output F 
it would work fine but when you then change display to C it would exhibit 
similar bad behaviour). There are a few options:

1. customise weeWX to archive appTemp, ie follow the instructions at Adding 
a new observation type 
 in 
the Customization Guide. Note that there is no need to add a service as 
appTemp is already calaculated, the only real change is that you need to 
add appTemp to the db and set its units. Pretty easy stuff.

2. set apptempL and apptempH both to 0. The light red wedge on the apparent 
temp gauge that shows the appTemp day range would not show, we can't make 
up data so no problems there. The mouseover plot would show the day low and 
high to be 0 (or maybe 32 deending on source and display units) - that will 
be wrong but at least it is largely hidden from the user. The autoscaling 
could have some issues if you were in a very hot location where all your 
temps (outTemp, windchill, heatindex, humidex, dewpoint, appTemp) were 
relatively high; the apptempL and apptempH values may skew the autoscaling 
to the lower end. But the nonsense behaviour currently happening would not 
occur.

3. set apptempL and apptempH both to the current appTemp value. Again the 
light red wedge on the apparent temp gauge that shows the appTemp day range 
would not show. The mouseover plot would show the day low and high to be 
whatever the current appTemp value is - again that will be wrong but at 
least it is largely hidden from the user. The autoscaling would not be 
uspet (ie skewed) under any circumstances.

4. use weeWX-WD to record appTemp in a separate database. This has all the 
advantages of 1. without the need to chnage the weeWX database (which is 
not really an issue). I don't think this is a practical solution, its a bit 
like buying a Mack truck just to take a trip to the corner store for the 
paper each day (and finding your truck probably breaks down once a month!).

At the moment I am leaning towards a hybrid; look for a day low/high appTemp, 
if they are available use them, otherwise set both to the current appTemp 
value. I could probably include a silent option in the rtgd config to 
specify a binding from where to get appTemp data which would default to 
wx_binding (the weeWX default binding) (I have my appTemp data in a 
separate datbase so this ability will almost certainly be included :) )

Gary

On Sunday, 19 February 2017 11:43:42 UTC+10, gjr80 wrote:
>
> Yes,  thought it would, my gauges exhibit the same behaviour. The 
> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
> need to sit down and work through the data. 
>
> Of course,  we could just disable F :) 
>
> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Saturday, February 18, 2017 at 5:56:41 PM UTC-8, tempus wrote:
>
> On Saturday, February 18, 2017 at 5:43:42 PM UTC-8, gjr80 wrote:
>>
>> Yes,  thought it would, my gauges exhibit the same behaviour. The 
>> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
>> need to sit down and work through the data. 
>>
>> Of course,  we could just disable F :) 
>>
>> Gary
>>
>>
>> I will have a look at the code myself when I have time. 
>
> While you are looking, I noticed another issue. The gauge wind speed is 
> 0.1 MPH less than shown on the Davis console.
>
> 1 MPH shows as 0.9 MPH
> 2 MPH shows as 1.9 MPH
> 3 MPH shows as 2.9 MPH
> etc.
>
> Bob
>

Maybe the Davis console display rounds-up. I just saw the gauge and Davis 
both display 2 MPH after several times where Davis displayed 2 and the 
gauge displayed 1.9.

Bob

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Saturday, February 18, 2017 at 5:43:42 PM UTC-8, gjr80 wrote:
>
> Yes,  thought it would, my gauges exhibit the same behaviour. The 
> SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I 
> need to sit down and work through the data. 
>
> Of course,  we could just disable F :) 
>
> Gary
>
>
> I will have a look at the code myself when I have time. 

While you are looking, I noticed another issue. The gauge wind speed is 0.1 
MPH less than shown on the Davis console.

1 MPH shows as 0.9 MPH
2 MPH shows as 1.9 MPH
3 MPH shows as 2.9 MPH
etc.

Bob

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Gary Roderick]

Yes,  thought it would, my gauges exhibit the same behaviour. The
SteelSeries gauges do a lot of funky stuff to calculate gauge scales etc, I
need to sit down and work through the data.

Of course,  we could just disable F :)

Gary

On 19/02/2017 11:28 AM, "tempus"  wrote:
>
> On Saturday, February 18, 2017 at 3:19:44 PM UTC-8, gjr80 wrote:
>>
>> Bob,
>>
>> If you want to try the realtime gauge-gate.txt you can find it here:
>>
>> https://github.com/gjr80/weewx-realtime_gauge-data
>>
>> Extension package is under the releases tab, install instructions are in
the readme.
>>
>> Gary
>
>
> It is installed and running with the same F scaling problem.
>
> Bob
>
> --
> 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.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Saturday, February 18, 2017 at 3:19:44 PM UTC-8, gjr80 wrote:
>
> Bob,
>
> If you want to try the realtime gauge-gate.txt you can find it here:
>
> https://github.com/gjr80/weewx-realtime_gauge-data
>
> Extension package is under the releases tab, install instructions are in 
> the readme.
>
> Gary
>

It is installed and running with the same F scaling problem.

Bob 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Saturday, February 18, 2017 at 3:19:44 PM UTC-8, gjr80 wrote:
>
> Bob,
>
> If you want to try the realtime gauge-gate.txt you can find it here:
>
> https://github.com/gjr80/weewx-realtime_gauge-data
>
> Extension package is under the releases tab, install instructions are in 
> the readme.
>
> Gary
>

Thanks. I will give it a try.

Bob 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

That F behaviour is somewhat bizarre, especially as indoor works. There is no 
difference in how indoor is produced compared to outdoor. I will have a look at 
that later today.

Not so convinced about the wind cause, still looking at that one.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Bob,

If you want to try the realtime gauge-gate.txt you can find it here:

https://github.com/gjr80/weewx-realtime_gauge-data

Extension package is under the releases tab, install instructions are in the 
readme.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Nigel Head]

Hadn't noticed that - 'wind chill' etc is the same when selecting
Fahrenheit.
When selecting 'inside' for Fahrenheit temp, it scales fine.

Gary has fixed the 'red face' problem now.

Nigel.

On 18 February 2017 at 15:53, tempus  wrote:

>
> On Tuesday, February 14, 2017 at 7:30:53 AM UTC-8, Devonian wrote:
>>
>> I have been working with Gary (gjr80) - well, Gary has done all the work
>> and I am beta testing.
>> We have a working real-time-gauge-data py file that creates a
>> gauge-data.txt file on definable loop packets, upto every 2.5 seconds on a
>> VP2.
>>
>> Gary will no doubt update when he is happy to release it, in the
>> meantime, mine is on test here (on 5 second updates, at every other loop)
>>
>> http://www.nthead.co.uk/ss/index.html
>>
>> Nigel.
>>
>
> I noticed that the temperature gauge scaling is wrong if Fahrenheit is
> selected.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/weewx-user/f4qQyOJ1C-M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@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] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 3:34:29 PM UTC-8, gjr80 wrote:
>
> One of the challenges when driving the SteelSeries gauges is that there is 
> a lot of information being conveyed by the gauges other than just the 
> simple gauge value. In the case of the red faced gauge it was simply a case 
> of a mis-constructed query that was returning incorrect pressL and pressH 
> values. These contribute to part of the shading of the pressure gauge.
>
> I had not noticed the linear shading of the wind direction gauge, I would 
> expect to see something like that under the simulator but not in real life. 
> I implemented a revised method of producing the windrose data, and whilst 
> the windrose gauge is not being displayed, the windrose data may have an 
> effect on the wind direction gauge. This one I will need to look at more 
> closely.
>
> Gary
>
>
Gary, it is obvious from watching the gauges for a while that the linear 
shading of the wind direction gauge is due to the wind direction being 
falsely reported as North when the wind speed is zero. The shading could be 
fixed by simply leaving the direction indication unchanged whenever the 
wind speed is zero.

Bob

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 3:34:29 PM UTC-8, gjr80 wrote:
>
> One of the challenges when driving the SteelSeries gauges is that there is 
> a lot of information being conveyed by the gauges other than just the 
> simple gauge value. In the case of the red faced gauge it was simply a case 
> of a mis-constructed query that was returning incorrect pressL and pressH 
> values. These contribute to part of the shading of the pressure gauge.
>
> I had not noticed the linear shading of the wind direction gauge, I would 
> expect to see something like that under the simulator but not in real life. 
> I implemented a revised method of producing the windrose data, and whilst 
> the windrose gauge is not being displayed, the windrose data may have an 
> effect on the wind direction gauge. This one I will need to look at more 
> closely.
>
> Gary
>
> On Wednesday, 15 February 2017 07:55:41 UTC+10, Devonian wrote:
>>
>> @Bob,
>>
>> Maybe the gauge is angry or embarrassed ;-)
>>
>> It's not polished yet and Gary will no doubt fix it up in due course as 
>> it's just cosmetics.
>> The wind direction colours are a little wrong as well as they progress 
>> from pale blue to red in a continuous colour change as opposed to 
>> reflecting the direction of predominant wind with variables either side, as 
>> you might expect.
>>
>> Nigel.
>>  
>>
>
Gary, let me know if you would like an additional beta tester.

Bob 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 7:30:53 AM UTC-8, Devonian wrote:
>
> I have been working with Gary (gjr80) - well, Gary has done all the work 
> and I am beta testing.
> We have a working real-time-gauge-data py file that creates a 
> gauge-data.txt file on definable loop packets, upto every 2.5 seconds on a 
> VP2.
>
> Gary will no doubt update when he is happy to release it, in the meantime, 
> mine is on test here (on 5 second updates, at every other loop)
>
> http://www.nthead.co.uk/ss/index.html
>
> Nigel.
>

I noticed that the temperature gauge scaling is wrong if Fahrenheit is 
selected.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 7:48:18 AM UTC-8, tempus wrote:
>
> On Tuesday, February 14, 2017 at 6:47:13 AM UTC-8, tempus wrote:
>>
>> Gosh - First mistake you ever made!!!
>>
>> I will try the fix. Thanks for your quick response.
>>
>> Bob
>>
>> On Tuesday, February 14, 2017 at 4:40:50 AM UTC-8, mwall wrote:
>>>
>>> sorry, again.  please use crt-0.20rc2.py
>>>
>>>
> crt-0.20rc2.py has only been running a few minutes, but seems to work. 
> Thanks for the fix..
>  
> Bob
>
> I left on a trip right after upgrading to 0.20 rc2 and the gauges had 
starting working.  Since arriving back last night gauge temperatures are 
-20 degrees, pressure is 990, and everything else is zero, like before the 
upgrade.  realtimegaugesT.txt is still updating at approximately 2.5 second 
intervals and the data looks valid, but it isn't getting to the gauges.

Any ideas?

-Bob
 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Quite some time ago when I produced a loop based clientraw.txt (for 
realtime update of the Saratoga dashboard). All was well whilst weeWX and 
my web server were on the same machine. About 18 months ago I moved weeWX 
to a new machine and I was left with no means of realtime transfer of 
clientraw.txt to my web server. I did create a loop based rsync service 
that rsync'ed clientraw.txt every loop period, the service essentially 
consisted of putting the the rsync code into its own service with a binding 
to NEW_LOOP_PACKET to fire the rsync. It was a little crude but worked, 
although some of its limitations came through when I created a loop based 
customclientraw.txt (superseded by gauge-data.txt) to drive the SteelSeries 
Gauges. I had intended to redo the my rsync service such that rsync ran in 
its own thread monitoring a queue for 'rsync jobs' and recently I had the 
impetous to finish it off. It seems to work well, any of the services that 
generate realtime files just place a file name in the queue and the rsync 
service takes care of it.Whilst running in a thread is a little more 
complex, performance is much better with little impact during the 
(substantial) report cycle on my weeWX machine.

Gary

On Tuesday, 14 February 2017 03:50:56 UTC+10, Tom Keffer wrote:
>
> That could work. With this thinking, we could even do away with the report 
> generator. Instead, image generation and file generation would be separate 
> weewx services. Each would invoke its own FTP session when done. Because 
> the set of generated files are disjoint, there would be no duplicated 
> effort (although there could be multiple simultaneous FTP sessions).
>
> I believe the module ftpupload is pretty standalone. There's nothing in 
> there that depends on the report generator framework.
>
> -tk
>
> On Mon, Feb 13, 2017 at 9:44 AM, mwall  > wrote:
>
>> On Monday, February 13, 2017 at 12:19:40 PM UTC-5, Tom Keffer wrote:
>>>
>>> someone should write an rsync and an ftp service that can be bound to 
 NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync 
 reports, 
 just wrapped in a StdService instead of report generator.

>>> ​
>>> The problem with this approach is that then you need some sort of lock 
>>> for the FTP service, so it knows when the reporting thread is done.
>>>
>>> Hence the decision to put the FTP and reporting in the same thread, run 
>>> by the same generator.
>>>
>>
>> that makes sense.  and it works really well for reports.
>>
>> but there is a need for a general approach to doing transfer/sync outside 
>> of the StdReport framework.
>>
>> what if the ftp/rsync were a black box that any service could initiate?  
>> for example, as soon as it finished its 'work', the crt extension could 
>> start an ftp/rsync process.  or a json or csv extension, as soon as they 
>> finish writing, could start an ftp/rsync process.
>>
>> so the notion of a transfer/sync could be a feature that any service 
>> could easily implement, and there would be a standard 
>> 'transfer/sync-parameters' stanza analogous to database bindings.
>>
>> (doing real-time feeds with mqtt, influx, emoncms, etc gets the job done 
>> but with a totally different approach)
>>
>> 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+...@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] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

One of the challenges when driving the SteelSeries gauges is that there is 
a lot of information being conveyed by the gauges other than just the 
simple gauge value. In the case of the red faced gauge it was simply a case 
of a mis-constructed query that was returning incorrect pressL and pressH 
values. These contribute to part of the shading of the pressure gauge.

I had not noticed the linear shading of the wind direction gauge, I would 
expect to see something like that under the simulator but not in real life. 
I implemented a revised method of producing the windrose data, and whilst 
the windrose gauge is not being displayed, the windrose data may have an 
effect on the wind direction gauge. This one I will need to look at more 
closely.

Gary

On Wednesday, 15 February 2017 07:55:41 UTC+10, Devonian wrote:
>
> @Bob,
>
> Maybe the gauge is angry or embarrassed ;-)
>
> It's not polished yet and Gary will no doubt fix it up in due course as 
> it's just cosmetics.
> The wind direction colours are a little wrong as well as they progress 
> from pale blue to red in a continuous colour change as opposed to 
> reflecting the direction of predominant wind with variables either side, as 
> you might expect.
>
> Nigel.
>  
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

@Bob,

Maybe the gauge is angry or embarrassed ;-)

It's not polished yet and Gary will no doubt fix it up in due course as 
it's just cosmetics.
The wind direction colours are a little wrong as well as they progress from 
pale blue to red in a continuous colour change as opposed to reflecting the 
direction of predominant wind with variables either side, as you might 
expect.

Nigel.
 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 6:47:13 AM UTC-8, tempus wrote:
>
> Gosh - First mistake you ever made!!!
>
> I will try the fix. Thanks for your quick response.
>
> Bob
>
> On Tuesday, February 14, 2017 at 4:40:50 AM UTC-8, mwall wrote:
>>
>> sorry, again.  please use crt-0.20rc2.py
>>
>>
crt-0.20rc2.py has only been running a few minutes, but seems to work. 
Thanks for the fix..
 
Bob

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

On Tuesday, February 14, 2017 at 7:30:53 AM UTC-8, Devonian wrote:
>
> I have been working with Gary (gjr80) - well, Gary has done all the work 
> and I am beta testing.
> We have a working real-time-gauge-data py file that creates a 
> gauge-data.txt file on definable loop packets, upto every 2.5 seconds on a 
> VP2.
>
> Gary will no doubt update when he is happy to release it, in the meantime, 
> mine is on test here (on 5 second updates, at every other loop)
>
> http://www.nthead.co.uk/ss/index.html
>
> Nigel.
>

 I like the wind direction indicator a lot, but wonder why the Pressure 
normal-range is red.

Bob
 

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

I have been working with Gary (gjr80) - well, Gary has done all the work 
and I am beta testing.
We have a working real-time-gauge-data py file that creates a 
gauge-data.txt file on definable loop packets, upto every 2.5 seconds on a 
VP2.

Gary will no doubt update when he is happy to release it, in the meantime, 
mine is on test here (on 5 second updates, at every other loop)

http://www.nthead.co.uk/ss/index.html

Nigel.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Gosh - First mistake you ever made!!!

I will try the fix. Thanks for your quick response.

Bob

On Tuesday, February 14, 2017 at 4:40:50 AM UTC-8, mwall wrote:
>
> sorry, again.  please use crt-0.20rc2.py
>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[mwall]

sorry, again.  please use crt-0.20rc2.py

-- 
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.
# $Id: crt.py 1665 2017-01-29 00:41:10Z mwall $
# Copyright 2013-2017 Matthew Wall
# Distributed under terms of the GPLv3
# thanks to gary roderick for significant contributions to this code

"""Emit loop data to file in Cumulus realtime format.

   http://wiki.sandaysoft.com/a/Realtime.txt
   http://wiki.sandaysoft.com/a/Webtags

Nominally this will output to a file called realtime.txt every at LOOP packet.
It can be configured to output at every archive record instead of each LOOP.
Optionally it will output to one or more of the following:

  realtime.xml   - XML format of realtime data
  sunbird- sunrise, sunset, and location information
  realtimegauges.txt - the MX format

To install, put this file in bin/user/crt.py, then add this to your weewx.conf:

[CumulusRealTime]
filename = /path/to/realtime.txt

[Engine]
[[Services]]
archive_services = ..., user.crt.CumulusRealTime

If no unit_system is specified, the units will be those of the database.

Other parameters may be specified to control units and output:

[CumulusRealTime]
realtime_txt = /path/to/realtime.txt
realtime_xml = /path/to/realtime.xml
sunbird = /path/to/sunbird.txt
realtimegauges_txt = /path/to/realtimegaugesT.txt
date_separator = /
none = NULL
unit_system = (US | METRIC | METRICWX)
wind_units = (meter_per_second | mile_per_hour | km_per_hour | knot)
temperature_units = (degree_C | degree_F)
pressure_units = (hPa | mbar | inHg)
rain_units = (mm | inch)
cloudbase_units = (foot | meter)

Note that most of the code in this file is to calculate/lookup data that
are not directly provided in a LOOP packet.

The cumulus 'specification' for realtime.txt is ambiguous in places:

  - pressure trend interval is not specified, we use 3 hours for pressure
  - temperature trend interval is not specified, we use 3 hours for temperature
  
The following assumptions are based on the Cumulus realtime and webtag docs:
  - wind avg speed/wind avg dir interval is not specified. The equivalent 
Cumulus Webtags for wind avg speed and avg wind direction default to 
10 minute averages so we use 10 minutes as well.
  - wind direction bearings in degrees are set from > 0 to 360 with 0
indicating calm.  refer to the #avgbearing Webtag. this is different to
the standard used in weewx.
  - possible Cumulus windrun units are km, miles, km and nm corresponding to 
wind speeds in m/s, mph, km/h, kts.  weewx does not know what a nautical
mile (nm) is.
  
The following assumptions are based on examination of realtime.txt instances
from a number of live Cumulus sites:
  - time zone is not specified, local time is used throughout
  - how to handle None/NULL is not specified.  Examination of realtime.txt 
from a number of live Cumulus sites indicates when there is no wind 
(average or gust) wind speeds are set to zero. For other fields that
may be None/Null we return the 'none' parameter setting (default = NULL) 
from the weewx.conf [CumulusRealTime] section.
  - ordinal wind directions are set to --- when there is no wind.
"""

# FIXME: implement the additional xml parameters for records and yesterday

# FIXME: consider in-memory caching so that database queries are not
#necessary after the first invocation

import math
import time
import syslog
from distutils.version import StrictVersion

import weewx
import weewx.almanac
import weewx.manager
import weewx.wxformulas
import weeutil.weeutil
import weedb
from weewx.engine import StdService

VERSION = "0.20rc2"

REQUIRED_WEEWX = "3.5.0"
if StrictVersion(weewx.__version__) < StrictVersion(REQUIRED_WEEWX):
raise weewx.UnsupportedFeature("weewx %s or greater is required, found %s"
   % (REQUIRED_WEEWX, weewx.__version__))

def logmsg(level, msg):
syslog.syslog(level, 'crt: %s' % msg)

def logdbg(msg):
logmsg(syslog.LOG_DEBUG, msg)

def loginf(msg):
logmsg(syslog.LOG_INFO, msg)

def logerr(msg):
logmsg(syslog.LOG_ERR, msg)


# FIXME: get these from the forecast extension
# FIXME: ensure the forecast extension makes these available via i18n
FORECAST_TEXT = {
'A': 'Settled fine',
'B': 'Fine weather',
'C': 'Becoming fine',
'D': 'Fine, becoming less settled',
'E': 'Fine, possible showers',
'F': 'Fairly fine, improving',
'G': 'Fairly fine, possible showers early',
'H': 'Fairly fine, showery later',
'I': 'Showery early, improving',
'J': 'Changeable, mending',
'K': 'Fairly fine, showers likely',
'L': 'Rather unsettled clearing later',
'M': 'Unsettled, probably improving',
'N': 

[weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[mwall]

and here is 0.20rc1

-- 
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.
# $Id: crt.py 1665 2017-01-29 00:41:10Z mwall $
# Copyright 2013-2017 Matthew Wall
# Distributed under terms of the GPLv3
# thanks to gary roderick for significant contributions to this code

"""Emit loop data to file in Cumulus realtime format.

   http://wiki.sandaysoft.com/a/Realtime.txt
   http://wiki.sandaysoft.com/a/Webtags

Nominally this will output to a file called realtime.txt every at LOOP packet.
It can be configured to output at every archive record instead of each LOOP.
Optionally it will output to one or more of the following:

  realtime.xml   - XML format of realtime data
  sunbird- sunrise, sunset, and location information
  realtimegauges.txt - the MX format

To install, put this file in bin/user/crt.py, then add this to your weewx.conf:

[CumulusRealTime]
filename = /path/to/realtime.txt

[Engine]
[[Services]]
archive_services = ..., user.crt.CumulusRealTime

If no unit_system is specified, the units will be those of the database.

Other parameters may be specified to control units and output:

[CumulusRealTime]
realtime_txt = /path/to/realtime.txt
realtime_xml = /path/to/realtime.xml
sunbird = /path/to/sunbird.txt
realtimegauges_txt = /path/to/realtimegaugesT.txt
date_separator = /
none = NULL
unit_system = (US | METRIC | METRICWX)
wind_units = (meter_per_second | mile_per_hour | km_per_hour | knot)
temperature_units = (degree_C | degree_F)
pressure_units = (hPa | mbar | inHg)
rain_units = (mm | inch)
cloudbase_units = (foot | meter)

Note that most of the code in this file is to calculate/lookup data that
are not directly provided in a LOOP packet.

The cumulus 'specification' for realtime.txt is ambiguous in places:

  - pressure trend interval is not specified, we use 3 hours for pressure
  - temperature trend interval is not specified, we use 3 hours for temperature
  
The following assumptions are based on the Cumulus realtime and webtag docs:
  - wind avg speed/wind avg dir interval is not specified. The equivalent 
Cumulus Webtags for wind avg speed and avg wind direction default to 
10 minute averages so we use 10 minutes as well.
  - wind direction bearings in degrees are set from > 0 to 360 with 0
indicating calm.  refer to the #avgbearing Webtag. this is different to
the standard used in weewx.
  - possible Cumulus windrun units are km, miles, km and nm corresponding to 
wind speeds in m/s, mph, km/h, kts.  weewx does not know what a nautical
mile (nm) is.
  
The following assumptions are based on examination of realtime.txt instances
from a number of live Cumulus sites:
  - time zone is not specified, local time is used throughout
  - how to handle None/NULL is not specified.  Examination of realtime.txt 
from a number of live Cumulus sites indicates when there is no wind 
(average or gust) wind speeds are set to zero. For other fields that
may be None/Null we return the 'none' parameter setting (default = NULL) 
from the weewx.conf [CumulusRealTime] section.
  - ordinal wind directions are set to --- when there is no wind.
"""

# FIXME: implement the additional xml parameters for records and yesterday

# FIXME: consider in-memory caching so that database queries are not
#necessary after the first invocation

import math
import time
import syslog
from distutils.version import StrictVersion

import weewx
import weewx.almanac
import weewx.manager
import weewx.wxformulas
import weeutil.weeutil
import weedb
from weewx.engine import StdService

VERSION = "0.20rc1"

REQUIRED_WEEWX = "3.5.0"
if StrictVersion(weewx.__version__) < StrictVersion(REQUIRED_WEEWX):
raise weewx.UnsupportedFeature("weewx %s or greater is required, found %s"
   % (REQUIRED_WEEWX, weewx.__version__))

def logmsg(level, msg):
syslog.syslog(level, 'crt: %s' % msg)

def logdbg(msg):
logmsg(syslog.LOG_DEBUG, msg)

def loginf(msg):
logmsg(syslog.LOG_INFO, msg)

def logerr(msg):
logmsg(syslog.LOG_ERR, msg)


# FIXME: get these from the forecast extension
# FIXME: ensure the forecast extension makes these available via i18n
FORECAST_TEXT = {
'A': 'Settled fine',
'B': 'Fine weather',
'C': 'Becoming fine',
'D': 'Fine, becoming less settled',
'E': 'Fine, possible showers',
'F': 'Fairly fine, improving',
'G': 'Fairly fine, possible showers early',
'H': 'Fairly fine, showery later',
'I': 'Showery early, improving',
'J': 'Changeable, mending',
'K': 'Fairly fine, showers likely',
'L': 'Rather unsettled clearing later',
'M': 'Unsettled, probably improving',
'N': 'Showery, bright intervals',

[weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[mwall]

On Tuesday, February 14, 2017 at 3:13:05 AM UTC-5, tempus wrote:
>
> Thanks for letting me know about that.
>
> I have a Vantage Pro2 Plus interfaced to weewx 3.6.2 via a USB 
> data-logger.  SteelSeries Weather Gauges 2.5.18 was already installed with 
> the following 'gauges.js' settings:
>
>   weatherProgram : 6,
>   realTimeUrlWeewx : 'gauge-data.txt',
>
> The gauges updated normally at five-minute intervals with that 
> configuration.
>
> After seeing your post I installed 'weewx-crt-0.18.tgz' and modified 
> 'weewx.conf' to create a realtime.txt file in the /ss/ directory of a test 
> website, like this:
>
> [CumulusRealTime]
>filename = /var/www/www.domain.com/ss/realtime.txt
>unit_system = US
>binding = loop
>
> When I restarted weewx a 'realtime.txt' file that appeared to contain 
> valid data was being written to the /ss/ directory at about three second 
> intervals, as expected.  That file can be remotely loaded in web browser, 
> so the Apache web server obviously has read-access.
>
> I then modified '/etc/weewx/skins/ss/scripts/gauges.js' by setting:
>
> weatherProgram : 0,
> realTimeUrlCumulus : 'realtime.txt',
>
> and deleted gauges.js at the website, so it would be replaced by the 
> modified version after weewx was restarted.
>
> A few minutes after restart I first verified that the modified 'gauges.js' 
> file had been copied to the website and then loaded the gauges webpage in a 
> web browser.  The gauges displayed, but had no data. Temperatures were -20 
> degrees, Pressure was 990, and everything else was zero.  
> '/ss/realtime.txt' still existed and was still updating at about 
> three-second intervals, but data in that file wasn't making it to the 
> gauges.
>
> The Apache access.log has '/ss/realtime.txt' successful access records at 
> about three-second intervals whenever the gauges webpage is loaded in a web 
> browser, so the file is being successfully accessed by webpage JavaScript 
> code, but data in the file has no effect on any of the gauges.
>
> Is the Cumulus-style 'realtime.txt' file produced by weewx-crt-0.18 known 
> to be compatible with SteelSeries Weather Gauges 2.5.18?
>>
>>
>>
bob, 

i misled you, but all is not lost.  the implementation got finished in my 
head, but not in the code :/

please try the attached crt-0.20rc1.py

just put it in place of your existing user/crt.py

you will need to add this to your weewx config:

[CumulusRealTime]
...
realtimegauges_txt = /var/www/www.domain.com/ss/realtimegaugesT.txt

and in /etc/weewx/skins/ss/scripts/gauges.js reset the cumulus url to:

realTimeUrlCumulus : 'realtimegaugesT.txt'

this implements many of the gauges fields, but not all of them.  the 
remaining ones can easily be added, but it was not clear to me whether that 
should be done using local running avg/min/max or repeated database 
queries.  you're welcome to hack on it until i have time to finish it up!

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Thanks for letting me know about that.

I have a Vantage Pro2 Plus interfaced to weewx 3.6.2 via a USB 
data-logger.  SteelSeries Weather Gauges 2.5.18 was already installed with 
the following 'gauges.js' settings:

  weatherProgram : 6,
  realTimeUrlWeewx : 'gauge-data.txt',

The gauges updated normally at five-minute intervals with that 
configuration.

After seeing your post I installed 'weewx-crt-0.18.tgz' and modified 
'weewx.conf' to create a realtime.txt file in the /ss/ directory of a test 
website, like this:

[CumulusRealTime]
   filename = /var/www/www.domain.com/ss/realtime.txt
   unit_system = US
   binding = loop

When I restarted weewx a 'realtime.txt' file that appeared to contain valid 
data was being written to the /ss/ directory at about three second 
intervals, as expected.  That file can be remotely loaded in web browser, 
so the Apache web server obviously has read-access.

I then modified '/etc/weewx/skins/ss/scripts/gauges.js' by setting:

weatherProgram : 0,
realTimeUrlCumulus : 'realtime.txt',

and deleted gauges.js at the website, so it would be replaced by the 
modified version after weewx was restarted.

A few minutes after restart I first verified that the modified 'gauges.js' 
file had been copied to the website and then loaded the gauges webpage in a 
web browser.  The gauges displayed, but had no data. Temperatures were -20 
degrees, Pressure was 990, and everything else was zero.  
'/ss/realtime.txt' still existed and was still updating at about 
three-second intervals, but data in that file wasn't making it to the 
gauges.

The Apache access.log has '/ss/realtime.txt' successful access records at 
about three-second intervals whenever the gauges webpage is loaded in a web 
browser, so the file is being successfully accessed by webpage JavaScript 
code, but data in the file has no effect on any of the gauges.

Is the Cumulus-style 'realtime.txt' file produced by weewx-crt-0.18 known 
to be compatible with SteelSeries Weather Gauges 2.5.18?

Bob

On Monday, February 13, 2017 at 9:16:48 AM UTC-8, mwall wrote:
>
> On Monday, February 13, 2017 at 11:49:48 AM UTC-5, tempus wrote:
>>
>> Has there been more progress on your new custom Service bound to the 
>> NEW_LOOP_PACKET event?  It would be great to have even a 
>> partially-functioning beta-version as a stop-gap solution.
>>
>
> bob,
>
> you could install the crt extension (cumulus realtime), and set its 
> binding to loop.  then install steel series and configure it to use the 
> cumulus realtime file for its input.
>
> https://github.com/weewx/weewx/wiki/crt
>
> this would work if weewx and the web/php server are on the same host
>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Thomas Keffer]

That could work. With this thinking, we could even do away with the report
generator. Instead, image generation and file generation would be separate
weewx services. Each would invoke its own FTP session when done. Because
the set of generated files are disjoint, there would be no duplicated
effort (although there could be multiple simultaneous FTP sessions).

I believe the module ftpupload is pretty standalone. There's nothing in
there that depends on the report generator framework.

-tk

On Mon, Feb 13, 2017 at 9:44 AM, mwall  wrote:

> On Monday, February 13, 2017 at 12:19:40 PM UTC-5, Tom Keffer wrote:
>>
>> someone should write an rsync and an ftp service that can be bound to
>>> NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports,
>>> just wrapped in a StdService instead of report generator.
>>>
>> ​
>> The problem with this approach is that then you need some sort of lock
>> for the FTP service, so it knows when the reporting thread is done.
>>
>> Hence the decision to put the FTP and reporting in the same thread, run
>> by the same generator.
>>
>
> that makes sense.  and it works really well for reports.
>
> but there is a need for a general approach to doing transfer/sync outside
> of the StdReport framework.
>
> what if the ftp/rsync were a black box that any service could initiate?
> for example, as soon as it finished its 'work', the crt extension could
> start an ftp/rsync process.  or a json or csv extension, as soon as they
> finish writing, could start an ftp/rsync process.
>
> so the notion of a transfer/sync could be a feature that any service could
> easily implement, and there would be a standard 'transfer/sync-parameters'
> stanza analogous to database bindings.
>
> (doing real-time feeds with mqtt, influx, emoncms, etc gets the job done
> but with a totally different approach)
>
> 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.
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[mwall]

On Monday, February 13, 2017 at 12:19:40 PM UTC-5, Tom Keffer wrote:
>
> someone should write an rsync and an ftp service that can be bound to 
>> NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports, 
>> just wrapped in a StdService instead of report generator.
>>
> ​
> The problem with this approach is that then you need some sort of lock for 
> the FTP service, so it knows when the reporting thread is done.
>
> Hence the decision to put the FTP and reporting in the same thread, run by 
> the same generator.
>

that makes sense.  and it works really well for reports.

but there is a need for a general approach to doing transfer/sync outside 
of the StdReport framework.

what if the ftp/rsync were a black box that any service could initiate?  
for example, as soon as it finished its 'work', the crt extension could 
start an ftp/rsync process.  or a json or csv extension, as soon as they 
finish writing, could start an ftp/rsync process.

so the notion of a transfer/sync could be a feature that any service could 
easily implement, and there would be a standard 'transfer/sync-parameters' 
stanza analogous to database bindings.

(doing real-time feeds with mqtt, influx, emoncms, etc gets the job done 
but with a totally different approach)

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.

Re: [weewx-user] Re: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Thomas Keffer]

>
> someone should write an rsync and an ftp service that can be bound to
> NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports,
> just wrapped in a StdService instead of report generator.
>
> ​
The problem with this approach is that then you need some sort of lock for
the FTP service, so it knows when the reporting thread is done.

Hence the decision to put the FTP and reporting in the same thread, run by
the same generator.

But, maybe there's some other clever way around this. I couldn't come up
with one...

I hate locks.

-tk​

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[mwall]

On Monday, February 13, 2017 at 11:49:48 AM UTC-5, tempus wrote:
>
> Has there been more progress on your new custom Service bound to the 
> NEW_LOOP_PACKET event?  It would be great to have even a 
> partially-functioning beta-version as a stop-gap solution.
>

bob,

you could install the crt extension (cumulus realtime), and set its binding 
to loop.  then install steel series and configure it to use the cumulus 
realtime file for its input.

https://github.com/weewx/weewx/wiki/crt

this would work if weewx and the web/php server are on the same host.

if they are on different hosts, then you'll need something to get the 
realtime.txt file from the weewx host to the web/php host each time the 
realtime.txt file changes.

unfortunately the ftp and rsync in weewx are designed to run as 'reports' 
on each archive interval, not on loop changes.

someone should write an rsync and an ftp service that can be bound to 
NEW_LOOP_PACKET.  it could use the same code used by the ftp/rsync reports, 
just wrapped in a StdService instead of report generator.

fwiw, a much cleaner way to do this would be to eliminate gauge-data.txt, 
realtime.txt, customraw.txt, and all of the php cruft.  just write a skin 
that uses the javascript gauges directly.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[tempus]

Has there been more progress on your new custom Service bound to the 
NEW_LOOP_PACKET event?  It would be great to have even a 
partially-functioning beta-version as a stop-gap solution.


Zambretti forecast data doesn't seem important, because those forecasts are 
so poor compared to forecasts readily available from multiple other sources 
as to reflect poorly on the likely reliability of everything being 
displayed.  Why not eliminate the Zambretti forecast and let users who want 
a forecast above the gauges include webpage code that will display a 
professional forecast obtained via the Forecast extension or other means?

Bob

On Monday, January 9, 2017 at 4:27:44 PM UTC-8, gjr80 wrote:
>
> Any chance you could use the NWS or WU current forecast for the 
>> tickertape/scroller in place of the Zambretti?
>>
>
> At the moment all I can do is pull the Zambretti forecast from the 
> forecast database (provided the forecast extension is installed), 
> unfortunately the WU and NWS forecast text is not saved in the forecast 
> database. I have had the WU forecast text being pulled in through weewx-WD 
> but that is something for the next version of weewx-WD and that is going to 
> be weeks away (at least).
>
> I might have a chat with Matthew and see what he may be prepared to do, 
> though I know he has a lot on at present.
>
> 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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

>
> Any chance you could use the NWS or WU current forecast for the 
> tickertape/scroller in place of the Zambretti?
>

At the moment all I can do is pull the Zambretti forecast from the forecast 
database (provided the forecast extension is installed), unfortunately the 
WU and NWS forecast text is not saved in the forecast database. I have had 
the WU forecast text being pulled in through weewx-WD but that is something 
for the next version of weewx-WD and that is going to be weeks away (at 
least).

I might have a chat with Matthew and see what he may be prepared to do, 
though I know he has a lot on at present.

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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Dan'l B]

Gary,

Any chance you could use the NWS or WU current forecast for the 
tickertape/scroller in place of the Zambretti?

An example is here 
, though 
it is accomplished using php.

On Sunday, January 8, 2017 at 5:50:40 PM UTC-5, gjr80 wrote:
>
> Hi Nigel,
>
> Yes, I have all the important bits working it was updating the SteelSeries 
> gauges on a VM just fine. Just want to get some forecast text from the 
> Zambretti forecaster if its installed and then package it up. That's where 
> I was on Friday when a couple of other things came up. Should be able to 
> get the rest dorted today or tomorrow.
>
> Gary
>
> On Monday, 9 January 2017 07:30:35 UTC+10, Devonian wrote:
>>
>> Hi Gary,
>>
>> Any luck on your 'custom' service?
>>
>> Nigel.
>>
>

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[Devonian]

Hi Gary,

That sounds like a perfect solution.
I did have Steel Series running since 2013-ish, when the first incarnations 
with weewx got going and it has worked well ever since on my WS2300 (albeit 
with 1 minute update).

I'm not too bothered about the wind rose, although it would be nice ;-)
I also have the Davis Solar and UV sensors, so for me, it would be great to 
have those included in the 2.5 sec update.

I am no software guru by any stretch of the imagination, but if I can be of 
any help, let me know.

Appreciate the help - have a virtual beer on me 

Nigel.

-- 
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: Steel Series Gauges and RealTime update - 2.5 second interval - how?

[gjr80]

Nigel,

I think a more elegant solution is to create a custom Service, bound to 
NEW_LOOP_PACKET event, that creates the JSON file used by the SteelSeries 
gauges after every loop packet arrives. I wrote such a service a couple of 
years back to produce customclientraw.txt on every x'th loop packet, put it 
away though when tracking down some issues and never got back to it. At the 
time the SteelSeries gauges did not directly support weewx, now that weewx 
is supported it would be a simple matter to rework the service to produce 
gauge-data.txt - its much the same data as customclientraw.txt and still 
JSON format. The only real issue is to what depth do you to populate the 
data file, for example, to get the current wind speed is trivial, getting 
todays max wind speed requires a little more effort, the windrose data a 
little more complex again and "the 'lowest' clockwise bearing in the last 
10 minutes rounded down to nearest 10 degrees" is getting right up there.

Give me a few days to see what I can resurrect.

Gary

On Monday, 2 January 2017 23:12:43 UTC+10, Devonian wrote:
>
> I have just invested in a Davis Vantage Pro2, which replaced my WS2300 and 
> have installed Weewx 3.6.2 on Debian ver8 replacing my previous weewx ver 
> 2.7 for the WS2300.
>
> I would like to get the Steel Series gauges performing real time updates 
> at the Davis loop interval of 2.5 seconds.
> I have them installed OK, but it uses my current archive interval of 5 
> minutes - not quite real time!
>
> I tried mesowx, but can't get the data to display - the page appears, but 
> no graphs.  Data is getting saved into my MySQL 'raw' database at regular 
> 2.5 second loop intervals.  I'll continue trying to figure this one out.
>
> So, my thoughts turned to using the raw database for Steel Series and to 
> use raw data instead of archive data.
> I'm primarily interested in wind speed/direction, so if I could only get 
> that to update @ 2.5 seconds, I'd be happy with the others at 5 minutes.
>
> Anyone got any ideas on how to use this raw data instead of archive?
> Maybe there's a better/simpler way to achieve this 2.5 second update?
>
> Regards,
>
> Nigel.
>

-- 
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.