Extension SteelSeries Weather Gauges

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've installed two extensions: SteelSeries Weather Gauges
(https://github.com/gjr80/weewx-steelseries) and Rtgd
(https://github.com/gjr80/weewx-realtime_gauge-data). A frequently
updated gauges-data.txt file is found at public_html/. A
less-frequently updated gauges-data.txt file is found at
public_html/ss/.

Both files are ftp'd to my web server, and — in fact — the page at
https://lacusveris.com/Weather/ss/index.html does find the frequently
updated gauges-data.txt file.

The SteelSeries Weather Gauges Extension specifies (in
ss/scripts/gauges.js) that, "The realtime files should be absolute
paths, "/xxx.txt" refers to the public root of your web server," but
the nearby specification:

> realTimeUrlWeewx : 'gauge-data.txt'

... does not appear to be an absolute path. I suppose IT IS though.

Of course, in weewx.conf [RealtimeGaugeData], rtgd_path is "Path to
gauge-data.txt. Relative paths are relative to HTML_ROOT. If empty[,]
HTML_ROOT is used."

In summary, each of the two extensions has a specification for the
path to the gauge-data.txt file, but one is absolute and one is
relative. Is there some way I can write the ss/scripts/gauges.js
specification so that gauge-data.txt can be found relative to
HTML_ROOT? It doesn't look like it.

I don't really want to hit my web server. Instead, I want to browse
locally to file:///home/ccrhode/weewx-data/public_html/ss/index.html
so that I can do away with my old Ambient USB console in favor of a
new console-less Ecowitt WiFi gateway and still see near realtime
indicators. Please tell me I'm being unreasonable.

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx
.. 55° — Wind WNW at 13 mph. Sky overcast.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaC+5VAAKCRBg2/xipKOW
UqhyAJ9awNSwF3BcMUb2ov/bD6YyXpItqACdG5assettwh4uO+7kz5dWwlil6EI=
=QzFE
-----END PGP SIGNATURE-----

[vince]

A file:// url is based on your host filesystem namespace but a https:// url is based on the webserver docroot, so unless your webserver docroot is / which would be a massive security risk, you are trying to do two conflicting things.  Why not just run a local webserver and hit that url ?

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 22 May 2025 17:23:13 -0700 (PDT)
vince <vince...@gmail.com> wrote:

> A file:// url is based on your host filesystem namespace but a
> https:// url is based on the webserver docroot, so unless your
> webserver docroot is / which would be a massive security risk, you
> are trying to do two conflicting things.

Hence my vain desire for a location for gauges-data.txt relative to
index.html rather than an absolute one.

> Why not just run a local webserver and hit that url ?

My Web Hosting Provider (WHP) takes a great deal of care to harden my
webserver for me. My opening a local webserver on my desktop machine
would expose me to a lot of unknown risk. I fool with *nginx* over
there, not over here.

P.S.: The same may be said for MQTT. I run a local
(non-websockets-capable) mosquitto broker, but I find all the
javascript libraries give that the horse-laugh. Would that browser
support for python scripting were more prevalent.... <sigh>

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 49° — Wind E at 9 mph. Sky overcast.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaC/IAQAKCRBg2/xipKOW
UiEpAJ9TC/K10j+V+uziG6wp6+K/lJwSdACeO9doFenrrozxZxiAcea3G3nHhqk=
=9u7V
-----END PGP SIGNATURE-----

[gjr80]

I thought I added a note to the effect, but it seems I have not. If you have installed both the weewx-steelseries and weewx-realtime_gauge-data extensions you should disable the weewx-steelseries generation of gauge-data.txt and delete from your web server and WeeWX machine any gauge-data.txt files previously generated by weewx-steelseries. Whilst the presence of gauge-data.txt from two different sources will not cause any WeeWX or web server errors per se, many users have experienced some weird/unexpected effects if the 'wrong' file is used by the SteelSeries gauges or the files overwrite each other on the WeeWX machine or web server. In my experience it is better to only have one gauge-data.txt source active at any one time.

Gary 

[Jimi Lawson]

I don't see how using a local webserver poses any risk ? 

That's what I do for local access to my station Weewx pages I run a Apache2 server on the Rpi 3b that runs my weather station so I can access my Weewx & Steel Series (different version,  https://github.com/HanSolo/SteelSeries-Canvas )  pages from a local LAN address (http://192.168.1.130/weewx/ss/) since it's behind my modem/router/firewall and not exposed to the WWW I don't see any security issues. 

My website station page is https://jlawson.co.uk/index.php/weather if you want to see how this version of Steel Series looks.

Regards

Jimi

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 22 May 2025 18:53:00 -0700 (PDT)
gjr80 <gjrod...@gmail.com> wrote:

> If you have installed both the weewx-steelseries and
> weewx-realtime_gauge-data extensions you should disable the
> weewx-steelseries generation of gauge-data.txt and delete from your
> web server and WeeWX machine any gauge-data.txt files previously
> generated by weewx-steelseries.

This can be achieved by commenting out the [[[data]]] stanza in
weewx-data/skins/ss/skin.conf:

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

I feel it's better to put the RTGD gauge-data.txt file closer to the
*.html files, so I modify the [RealtimeGaugeData] stanza in
weewx-data/weewx.conf, too:

> [RealtimeGaugeData] # 2025 May 22
>
> # Path to gauge-data.txt. Relative paths are relative to HTML_ROOT. If
> # empty HTML_ROOT is used, if setting omitted altogether /var/tmp is used.
> rtgd_path = ss # 2025 May 22

Then, the default setting for realTimeUrlWeewx in
weewx-data/skins/ss/scripts/gauges.js is correct:

> // The realtime files should be absolute paths,
> // "/xxx.txt" refers to the public root of your web server.
> realTimeUrlWeewx : 'gauge-data.txt', // *** WeeWX Users: Change to your location of the gauge data file ***

In spite of the bogus comment above, the gauge-data.txt file is loaded
from the same folder as index.html.

I receive a working page of gauges from my Web site at
https://lacusveris.com/Weather/ss/index.html even though the rsync
doesn't happen very often.

Bringing up a local copy
file:///home/ccrhode/weewx-data/public_html/ss/index.html in my
browser doesn't work at all, though. Apparently, this is due to
jquery.ajax's mistrust of local data. But wait! Hammering at the
Gates of Google yields this tidbit:

> chromium --allow-file-access-from-files /home/ccrhode/weewx-data/public_html/ss/index.html

... which sidesteps the issue. Firefox solutions involve relaxing
security policies with (for me) uncertain consequences.

Hooray! It appears to me that I'm able to browse a realtime local gauge
page and use that in place of a weather station console.

Finally, I am convicted to say that the SteelSeries Gauges are
heartbreakingly beautiful to look at and legible, too. And they have
tons of configurable options. I think something could be done with
providing a set of themes for users to play with in
weewx-data/skins/ss/skin.conf — much like what I've done for the
Seasons skin in my WeeWX Phenology extension:

https://lacusveris.com/Phenology/phenology_image_generator.shtml

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 53° — Wind NW at 9 mph. Sky overcast.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaDC4LgAKCRBg2/xipKOW
UoB9AJ0W99M54VVq1oojbnuoTJBIJ2h8QACfahggFmdDt4932lbkiulnJrz6fB8=
=0J7E
-----END PGP SIGNATURE-----

[Chuck Rhode]

On Fri, 23 May 2025 13:02:22 -0500
Chuck Rhode <charlescu...@gmail.com> wrote:

> > chromium --allow-file-access-from-files \
> > /home/ccrhode/weewx-data/public_html/ss/index.html

Once upon a time there was a --enable-file-cookies, too, but this is
gone from *chromium* nowadays apparently. I should point out that the
SteelSeries Gauges Extension does set cookies for the units radio
buttons so that these settings are preserved across browser sessions
but only for http:// protocol URLs. It does nothing to preserve
session settings for file:// protocol URLs due to limitations in
jview.ajax one supposes.

--
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 61° — Wind E at 8 mph. Sky clear.

[gjr80]

Probably worth while noting who's who in the zoo here...

The SteelSeries gauges by HanSolo can be found on GitHub - https://github.com/HanSolo/SteelSeries-Canvas.

The SteelSeries weather gauges by mcrossley, which uses the SteelSeries gauges, can be found on GitHub - https://github.com/mcrossley/SteelSeries-Weather-Gauges. Note the SteelSeries weather gauges includes support for a number PWS software suites, WeeWX being just one. The SteelSeries weather gauges repo includes a WeeWX skin and instructions to produce a WeeWX report based SteelSeries weather gauges page. WeeWX installation is a manual process; the repo does not include a WeeWX extension package. Mark is not a WeeWX user/developer (he maintains Cumulus) so don't expect too much from him re WeeWX issues with the SteelSeries weather gauges.

The weewx-steelseries extension takes the skin from the SteelSeries weather gauges repo and packages it as a WeeWX extension, nothing more. Consequently, the repo only contains the framework required for an extension, not the an actual StreelSeries weather gauges code/skin. I try to update this extension whenever a new SteelSeries weather gauges version is released.  It can be found on GitHub - https://github.com/gjr80/weewx-steelseries. 

The WeeWX Realtime gauge-data extension is a WeeWX extension I wrote that produces a loop based gauge-data.txt file, the data file used by the SteelSeries weather gauges. This allows for loop based updating of the SteelSeries weather gauges. It can be found on GitHub - https://github.com/gjr80/weewx-realtime_gauge-data.

Gary

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 25 May 2025 21:50:16 -0700 (PDT)
gjr80 <gjrod...@gmail.com> wrote:

> Probably worth while noting who's who in the zoo here...

I find that I've edited the following:

> ./weewx.conf
> ./skins/ss/scripts/gauges.js
> ./skins/ss/skin.conf
> ./skins/ss/css/gauges-ss.css

... so, for me, gauges are not as much carefree magic as a couple of
WeeWX extensions. The black magic, of course, is in gauges.js and its
included javascript libraries. There's no paramaterization of gauges'
appearance or even choice of gauges in skin.conf as a WeeWX user might
expect there to be. My knee-jerk reaction is that most of the
top-level logic of gauges.js ought to be dragged over to
./skins/ss/index.html.tmpl, but, as a Python enthusiast, I'm
disgustipated by javascript to the point that reverse-engineering it
is a noisome prospect.

There may be a half-way measure to be taken. I'm thinking the default
gauge appearance parameters structure could be exported from gauges.js
as a json file if it doesn't exist and imported to gauges.js to
overlay defaults if it does exist. This json file would be edited
once, but it could be created by a cheetah tmpl, too, except that
means it would be recreated in every report cycle doesn't it?
... which would be stupid. Gauge selection and layout is yet another
matter, though, but I'm thinking I'd tackle one or both issues ... in
my spare time naturally.

Gary, you've been through this rats' maze. Are there blind alleys I
should avoid?

- --

.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 55° — Wind NE at 9 mph. Sky clear.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaDR1QgAKCRBg2/xipKOW
UhUHAJ9znEUgMC/tC0PfSQOMVMiNaf8TWQCePu/0/0ecindSw4/O4lYNf9oQ6/E=
=Czkw
-----END PGP SIGNATURE-----

[gjr80]

I’m not sure what you are trying to achieve here, all of the ‘look and feel’ for the gauges is in gauges.js which resides in your (nominally) ss skin directory in ss/scripts. The usual process is to make any ‘look and feel’ changes to gauges.js and on a WeeWX restart gauges.js is uploaded to your web server and the changes take effect. The variables holding ‘look and feel’ settings in gauges.js are config (starting line 36), gaugeGlobals (starting line 90), commonParams (starting line 142). The init function starting at line 207 also has some WeeWX settings (starting at line 333). 

If you do pull all of these 'look and feel' settings out and put them in a template (or some other file) I’m not seeing the improvement; you still have to edit a file other than skin.conf/weewx.conf to change the gauges 'look and feel'. The current arrangement of having user config options in gauges.js along with the weather gauges code means that you need to take precautions or re-edit gauges.js each time there is an upgrade to the file. Can be annoying. If you use a template or a fixed .json file approach, you have all of your weather gauges settings in one place (well two actually because you will always have something in weewx.conf), but to do this you will need to insert some javascript code in gauges.js so you still have a manual edit process to go through with gauges.js should gauges.js be upgraded.

To me the real solution is to have the SteelSeries weather gauges author include support for ‘look and feel’ settings in a separate file. Whether he has any appetite for that I do not know. Also remember the SteelSeries weather gauges support a number of other PWS software suites not just WeeWX.

That being said I’ve learnt in my time with WeeWX that the user is always right. If you want to go down the path of modifying gauges.js to use external config settings if available I would be sticking to those ‘look and feel’ variables/function I mentioned above. Gong down further into the gauges.js code should not be necessary, and will likely drastically increase the risk of failure. Note that some of the ‘looking feel’ config settings used in gauges.js rely on variables in the underlying SteelSeries gauges code, eg line 102:

lcdColour             : steelseries.LcdColor.STANDARD

I've gone through a similar process in implementing Highcharts support. The beauty with Highcharts is that Highcharts is written to obtain config details from an external file. Unfortunately that is not the case with the SteelSeries weather gauges.

Gary

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 26 May 2025 22:21:08 -0700 (PDT)
gjr80 <gjrod...@gmail.com> wrote:

<snip>

> The usual process is to make any ‘look and feel’ changes to
> gauges.js and on a WeeWX restart gauges.js is uploaded to your web
> server and the changes take effect.

<snip>

> To me the real solution is to have the SteelSeries weather gauges
> author include support for ‘look and feel’ settings in a separate
> file.

I think you're right! ... and there ARE A LOT of settings!

+ https://nicolas-van.github.io/steelseries/

Click "Parameters" under <steelseries-radial>, where you can tweak
things and see the results in real time.

... or perhaps see:

+ https://www.wilmslowastro.com/steelseries/demoRadial.html

<snip>

> Note that some of the ‘looking feel’ config settings used in
> gauges.js rely on variables in the underlying SteelSeries gauges
> code, eg line 102:

> lcdColour : steelseries.LcdColor.STANDARD

<snip>

Yeah, those things are structures, not just integer enumerators, which
is pretty disturbing. Still, it should be doable to sus out the
supported values by examining the non-minified SteelSeries source
code. This may be that source code:

+ https://cdn.jsdelivr.net/npm/steel...@2.0.7/dist/steelseries.bundled.js

What we have here are constant structures that go by terse names
(BEIGE, BLUE, ORANGE, ... STANDARD) that can be assigned to parameters
with terse names (LcdColor). Clearly Users don't get to play with
combinations unless they're willing to wallow in the messy details.

To repeat previous posts, the designer did really nice work with
rendition. It looks like the code has a lot of if's, and's, and but's
to step around obvious conflicts between choices of values for
parameters.

My impression is that it should be possible to confine, to shape, and
to channel User choice and expectations by providing cascading themes
in skin.conf. (Necessarily terse) theme names would be provided
to duplicate all the settings of all the parameters. Also, there would
be theme names for more or less comprehensive combinations of detailed
themes, such as reverse-color schemes with dark dial faces. Finally
there would be global themes for arbitrary effects, such as steampunk.

See, for example, these real-life historical steam gauges at the
Cincinnati Water Works:

+ https://www.flickr.com/photos/33523379@N03/12879445113/in/album-72157641751207373/

One could specify a global effect and then override parts of it with
more specific themes, such as pointer type and color. One could
manage cascading themes in the *configobj* skin.conf file and mask
global settings with more specific ones in a python script to be
included in a cheetah generator *.tmpl file, and one could perhaps
write a *.json parameter file for gauges.js from that. It's hard to
set up, but dead easy for Users to use. The more global themes would,
of course, override the background and foreground colors for the
index.html page itself, which would require a mod to index.html.tmpl,
too.

Obviously these are just ramblings so far. You are correct, though.
I don't see any way to achieve this without modifying
scripts/gauges.js, which is obliterated with normal upgrades.

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 59° — Wind ENE at 9 mph. Sky overcast.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaDdIFwAKCRBg2/xipKOW
Ugy1AJ46yuv3N69tTAtbeFGc9a6OHrfuwwCbBkUPSd00pnmmDMxtwi5uvLDLumY=
=zFzf
-----END PGP SIGNATURE-----

[Benedict]

What happened to your github page, Gary ?

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 26 May 2025 22:21:08 -0700 (PDT)
gjr80 <gjrod...@gmail.com> wrote:

> If you want to go down the path of modifying gauges.js to use

> external config settings if available, I would be sticking to those

> ‘look and feel’ variables/function I mentioned above.

Yes, I did need to modify gauges.js, which makes this approach
inappropriate for a WeeWX extension. Nevertheless; to see examples of
SteelSeries Gauge Themes, navigate to:

+ https://lacusveris.com/Steelseries Gauges/

... where I provide lots of working code, instructions, and rationale
such as it is.

You can see (almost) live data at:

+ https://lacusveris.com/Weather/ss/

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx

.. 63° — Wind W at 5 mph. Sky clear; haze.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaEjXQAAKCRBg2/xipKOW
UucAAJ9Uhyv0B11rz3/+xUXAN3wXZ1uk0gCfQMBD2gfZgFrC/TQDtKL9C3X/Nw4=
=nE6r
-----END PGP SIGNATURE-----

[peterq...@gmail.com]

Any pointers to a source for the real time gauge extension? I get a 404 from the previous location. 

[vince]

https://web.archive.org/web/20200906015348/https://github.com/gjr80/weewx-realtime_gauge-data/   seems to be one copy you could download the pieces from if that is what you are referring to.

[p q]

yeah, I put the old SD card back in, rebooted, and got the old files back. 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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b9c42ab9-e144-4a3d-95ca-ad0068736f04n%40googlegroups.com.

--

Peter Quinn
(415)794-2264