Re: [weewx-user] Re: Steel Series Gauges - Graphs

[ewhain...@gmail.com]

I guess it took a little while to update, working properly now.

Thanks for the help!!!

On Wednesday, April 5, 2023 at 9:57:36 AM UTC-4 ewhain...@gmail.com wrote:

> So now I have most of the hover-over graphs showing in imperial. The 
> oddball is the temperature - the text shows correct and changes if I change 
> the radio button but the graph itself does not change from C.
> [image: Screenshot 2023-04-05 at 9.54.15 AM.png]
>
>
> On Tuesday, April 4, 2023 at 9:00:36 PM UTC-4 Ed Hainsworth wrote:
>
> Yes, those graphs. Thank you, I’ll give that a try
>
> Ed Hainsworth 
> ewhain...@gmail.com
>
> Sent from my iPhone
>
> On Apr 4, 2023, at 06:48, gjr80  wrote:
>
> By 'SteelSeries gauges graphs' I presume you mean the graphs that appear 
> when you mouseover the gauge faces. If so you should be able to change the 
> units used in the plots by changing the unit group settings in weewx.conf 
> [StdReport] [[SteelSeries]]. The default settings should look something 
> like:
>
>
> [StdReport]
> 
> [[SteelSeries]]
> 
> [[[Units]]]
> Groups
> group_altitude = foot  # foot or meter
> group_pressure = hPa   # hPa, inHg or mbar
> group_rain = mm# mm or inch
> group_rainRate = mm_per_hour   # mm_per_hour or 
> inch_per_hour
> group_speed = km_per_hour  # km_per_hour, 
> mile_per_hour,
># meter_per_second or knot
> group_temperature = degree_C   # degree_C or degree_F
>
> To change the temperature to display in Fahrenheit change degree_C to 
> degree_F, save the file and on the next report cycle the temperature 
> based plots should change to display Fahrehnheit. You can change any of 
> the unit group settings to suit, but note the SteelSeries gauges only 
> support a limited subset of the available WeeWX units.
>
> Note that change to these unit groups will also change the units appearing 
> in the gauge-data.txt file used by the SteelSeries gauges, this is fine 
> but you will find the default unit displayed on the gauges will be as set 
> above (which probably suits).
>
> Gary
> On Monday, 3 April 2023 at 23:24:20 UTC+10 ewhain...@gmail.com wrote:
>
> I don't know why I haven't noticed this before but my SteeleSeries gauges 
> graphs are showing metric data instead of imperial. 
>
> I have tried switching the radio buttons with no effect.
>
> How/where do I chnge these?
>
> Thanks
>
> -- 
> 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/n3g_ihfsjBo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/375b2be9-7ecc-4a94-b94e-f351e63b0a47n%40googlegroups.com
>  
> 
> .
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6b80b014-eb8f-4717-af70-eafb2b5d62d0n%40googlegroups.com.

Re: [weewx-user] Re: Steel Series Gauges - Graphs

[Ed Hainsworth]

Yes, those graphs. Thank you, I’ll give that a tryEd Hainsworth ewhainswo...@gmail.comSent from my iPhoneOn Apr 4, 2023, at 06:48, gjr80  wrote:By 'SteelSeries gauges graphs' I presume you mean the graphs that appear when you mouseover the gauge faces. If so you should be able to change the units used in the plots by changing the unit group settings in weewx.conf [StdReport] [[SteelSeries]]. The default settings should look something like:[StdReport]        [[SteelSeries]]                [[[Units]]]            Groups                group_altitude = foot  # foot or meter                group_pressure = hPa   # hPa, inHg or mbar                group_rain = mm        # mm or inch                group_rainRate = mm_per_hour   # mm_per_hour or inch_per_hour                group_speed = km_per_hour      # km_per_hour, mile_per_hour,                                               # meter_per_second or knot                group_temperature = degree_C   # degree_C or degree_FTo change the temperature to display in Fahrenheit change degree_C to degree_F, save the file and on the next report cycle the temperature based plots should change to display Fahrehnheit. You can change any of the unit group settings to suit, but note the SteelSeries gauges only support a limited subset of the available WeeWX units.Note that change to these unit groups will also change the units appearing in the gauge-data.txt file used by the SteelSeries gauges, this is fine but you will find the default unit displayed on the gauges will be as set above (which probably suits).GaryOn Monday, 3 April 2023 at 23:24:20 UTC+10 ewhain...@gmail.com wrote:I don't know why I haven't noticed this before but my SteeleSeries gauges graphs are showing metric data instead of imperial. I have tried switching the radio buttons with no effect.How/where do I chnge these?Thanks



-- 
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/n3g_ihfsjBo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/375b2be9-7ecc-4a94-b94e-f351e63b0a47n%40googlegroups.com.




-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/BA214007-FC81-48C5-B34B-ADAC2E6CC16E%40gmail.com.

[weewx-user] Re: Steel Series Gauges - Graphs

[gjr80]

By 'SteelSeries gauges graphs' I presume you mean the graphs that appear 
when you mouseover the gauge faces. If so you should be able to change the 
units used in the plots by changing the unit group settings in weewx.conf 
[StdReport] [[SteelSeries]]. The default settings should look something 
like:

[StdReport]

[[SteelSeries]]

[[[Units]]]
Groups
group_altitude = foot  # foot or meter
group_pressure = hPa   # hPa, inHg or mbar
group_rain = mm# mm or inch
group_rainRate = mm_per_hour   # mm_per_hour or 
inch_per_hour
group_speed = km_per_hour  # km_per_hour, mile_per_hour,
   # meter_per_second or knot
group_temperature = degree_C   # degree_C or degree_F

To change the temperature to display in Fahrenheit change degree_C to 
degree_F, save the file and on the next report cycle the temperature based 
plots should change to display Fahrehnheit. You can change any of the unit 
group settings to suit, but note the SteelSeries gauges only support a 
limited subset of the available WeeWX units.

Note that change to these unit groups will also change the units appearing 
in the gauge-data.txt file used by the SteelSeries gauges, this is fine but 
you will find the default unit displayed on the gauges will be as set above 
(which probably suits).

Gary
On Monday, 3 April 2023 at 23:24:20 UTC+10 ewhain...@gmail.com wrote:

> I don't know why I haven't noticed this before but my SteeleSeries gauges 
> graphs are showing metric data instead of imperial. 
>
> I have tried switching the radio buttons with no effect.
>
> How/where do I chnge these?
>
> Thanks
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/375b2be9-7ecc-4a94-b94e-f351e63b0a47n%40googlegroups.com.

[weewx-user] Re: Steel Series Gauges

[nineback]

I was testing the files on my local Window's Machine and getting the 
message.  Once I tested them on my off-site server all is well.

Tom

On Tuesday, January 1, 2019 at 10:30:52 AM UTC-6, nine...@gmail.com wrote:
>
> I installed the gauges uses the weex install script.  Files are being 
> produced in my var/www/html/weewx/ss directory.  When I run the index.html 
> file the gauges show up just fine except I get an error: in the led display 
> and no data is shown on the gauges.  I suspect it s something to do with 
> the location of the gauge-data.txt file but not sure?  The gauge-data.txt 
> file in the html/ss directory.
>
> Tom
>

-- 
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, 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 unsubs

[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
extraTemp1 = t_2
e

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

[gjr80]

Steve,

Have a look at the instructions here 
.
 
The basic formula is to get the extension installed and generating a loop 
based gauge-data.txt locally first then implement the HTTP POST - this will 
simplify any troubleshooting when/if the HTTP POST does not work.

I will preface these instructions with the caveat that I have not set this 
up with external hosting. I beleive that others may have, but my setup has 
been on my own host here at home. The overall process is correct but some 
of the precise steps may need fine tuning. See how you go.

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]

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]

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?

[tempus]

On Saturday, February 18, 2017 at 10:30:08 PM UTC-8, gjr80 wrote:
>
> 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
>

Sorry, I should have been more explicit. I didn't mean to suggest that you 
should include a better forecast in rtgd, but instead that if rtgd users 
want to display a forecast along with current conditions they can include a 
better forecast in their webpages by some means outside of rtgd (php 
include, HTML Server Side Include, widget on a WordPress page, HTML link to 
a forecast page, or whatever).

Current conditions and forecasts are, of course, much different.  Current 
conditions are facts, whereas forecasts are guesses about the future.  
Regardless of whether a forecast is based on rolling dice, the "educated 
guess" of a meteorologist, the output of a trained artificial neural net, 
an evolutionary algorithm, or other artificial intelligence engine of some 
kind, they are guesses that shouldn't be entangled with or 
mentally-confused with facts.  If guesses are going to be displayed along 
with facts, because they are far less accurate and potentially even grossly 
wrong, they should come after facts with clear demarcation and 
identification.

Where Zambretti forecasts are only marginally better than rolling dice, why 
degrade a page displaying facts by including them at the top?  Of course, 
rtgd users can easily disable or hide Zambretti forecasts if they don't 
want to display them, but why even bother to include them where they are 
not accurate and have nothing to do with current conditions displayed by 
the gauges?

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': 'Showery

[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,

Today for you is tomorrow for me ;-)

Thanks, really appreciate the effort.

g'night (or is that g'day?!)

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]

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,

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.

[weewx-user] Re: Steel Series gauges - cant alter chart popup size

[erbenton07]

Ok thanks Gary, Ill try that

-- 
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 - cant alter chart popup size

[gjr80]

Hi,

I am using the SteelSeries gauges in weewx 3.4.0 (I know, I need to upgrade 
> weewx and i will shortly)


Hey, if it works fine why mess with it.

As for the plots, you aren't doing anything wrong you are just not doing 
the right thing!

The [ImageGenerator] parameters control the properties of the generated 
images. In this case, you are altering the image_width and image_height 
properties and I presume (you do not say) the resulting image file(s) (not 
the display on your SteelSeries Weather Gauges page) will be 1080 px wide 
and 294 px high. On the other hand, the SteelSeries Weather Gauges uses CSS 
to set the width and height of the displayed tooltip graph. The values used 
in a default install are 438 px wide and 175 px high. So irrespective of 
the size of the image file you use as the tooltip graph, the SteelSeries 
Weather Gauges CSS will resize them to (by default) 438px by 175px. You can 
alter the size by editing the height and width settings of the .tipimg 
class in the SteelSeries Weather Gauges CSS file gauge-ss.css (have a look 
at the very end of the file) which you should find in the css directory in 
the directory on your web server holding the SteelSeries Weather Gauges 
source. If you do alter the gauge-ss.css file be aware that if you upgrade 
in future you run the risk of overwriting your changes.

Gary

On Monday, 31 October 2016 13:16:22 UTC+10, erbenton07 wrote:
>
> I am using the SteelSeries gauges in weewx 3.4.0 (I know, I need to 
> upgrade weewx and i will shortly)
> In weewx/skins/ss/skin.conf I changed the image height and width and 
> restarted weewx but don't see any chart popup size changes. Altering the 
> colors of x and y axis labels works ok but the image size is ignored.
> [ImageGenerator]
> image_width = 1080
> image_height = 294
> #image_width = 720
> #image_height = 196
> What I am doing wrong?
> Thanks
>

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