[weewx-user] Re: Months of missing NOAA reports

['Chris Schram' via weewx-user]

On 2021-06-15, Karen K  wrote:
> --=_Part_836_1870019296.1623761496670
> Content-Type: multipart/alternative; 
>   boundary="=_Part_837_178574929.1623761496670"
>
> --=_Part_837_178574929.1623761496670
> Content-Type: text/plain; charset="UTF-8"
>
> First of all, have a look at the logs. If there are errors, there are 
> messages.
>
> Then, if you want help and the messages do not explain it to you, send 
> information according to that instruction 
>.
>
> Chris Schram schrieb am Dienstag, 15. Juni 2021 um 13:59:51 UTC+2:
>
>> Oops! When my wife just asked me for the total rain from a recent storm,
>> I learned that I have not been updating or creating any NOAA reports
>> since late February of this year.
>>
>> That may be the time I replaced my Vantage Vue sensor suite and/or
>> replaced my Raspberry Pi with a newer model. At that time I migrated my
>> existing database, weewx.conf and slightly tweaked Standard skin, and
>> this is the first I've noticed any problem.
>>
>> I get a 404 error when I try to view the missing data, so that tells me
>> It's not being generated at all. Where to I start looking for what I
>> screwed up? Thanks.

"Look at the logs." What a concept ;-}

Numerous lines like this one:
Jun 15 13:10:15 raspberrypi weewx[560] ERROR weewx.cheetahgenerator:
  FileNotFoundError: [Errno 2] No such file or directory:
'/etc/weewx/skins/Standard/NOAA/NOAA-.txt.tmpl'

Looks like I got caught up in the hairball of UTF-8 switching to ASCII.
All fixed noe (I think). Thanks Karen

-- 
chrisp...@me.com is a filtered spam magnet. Email replies may be lost.
You're better off replying to this newsgroup.

-- 
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/sab77u%2413ja%241%40ciao.gmane.io.

[weewx-user] Re: Added wind speed measurements display with excess decimal places

[gjr80]

When you added your new fields did you assign them to a unit group? You 
need to do this if you want to make use of the WeeWX formatting and unit 
conversion capabilities in reports for your new fields. If you don't assign 
a field to a unit group then WeeWX does not know if it is a speed, a 
temperature or a pressure etc and the field will be displayed 'as is' in 
reports. To add your fields to a unit group add something like the 
following to the bottom of /usr/share/weewx/user/extensions.py (or 
depending on your WeeWX installation type /home/weewx/bin/user/extensions.py) 
(untested):

import weewx.units
weewx.units.obs_group_dict['WindSpeed2avg'] = 'group_speed'
weewx.units.obs_group_dict['WindGust10avg'] = 'group_speed'

You will need to restart WeeWX for the changes to take effect.

Gary
On Wednesday, 16 June 2021 at 09:33:11 UTC+10 Ron Walker wrote:

>
> I am running Weewx version 4.3 on a Raspberry Pi 3 which is running 
> Raspbian 9.  I added two wind speed measurements, WindSpeed2avg and 
> WindGust10avg, which show wind speed averaged over 2 minutes and wind gusts 
> averaged over 10 minutes respectively.
>
> When the values are displayed on the webpage they display with 6 decimal 
> places.  The same is true for the wind direction associated with each 
> measurement.  For example, wind speed 2 min average displays 8.389286 NE 
> (35.321429) and direction does not display the degree symbol.
>
> I've looked in the units.py file, but did not see anything there.  Can 
> anyone tell me where I can make the proper adjustments to the way these 
> values display?
>
> Thanks in advance!
>
> Ron
>

-- 
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/87529e82-e371-440f-8424-3a55c22c10d7n%40googlegroups.com.

[weewx-user] Added wind speed measurements display with excess decimal places

['Ron Walker' via weewx-user]

I am running Weewx version 4.3 on a Raspberry Pi 3 which is running 
Raspbian 9.  I added two wind speed measurements, WindSpeed2avg and 
WindGust10avg, which show wind speed averaged over 2 minutes and wind gusts 
averaged over 10 minutes respectively.

When the values are displayed on the webpage they display with 6 decimal 
places.  The same is true for the wind direction associated with each 
measurement.  For example, wind speed 2 min average displays 8.389286 NE 
(35.321429) and direction does not display the degree symbol.

I've looked in the units.py file, but did not see anything there.  Can 
anyone tell me where I can make the proper adjustments to the way these 
values display?

Thanks in advance!

Ron

-- 
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/6f133371-3f08-4c9a-98cc-f81fc5be45d6n%40googlegroups.com.

[weewx-user] Re: weewx stopped for no apparent reason

[Jay Jaeger]

FYI, now that I am monitoring for the WARNING messages, I am seeing them 
like clockwork every 5 minutes - in the SAME SECOND for which I see weewx 
"Added record" messages.  Doubt it is a coincidence - correlation is nearly 
99% (once in a while there is no WARNING.  Suggest only issuing the warning 
if >= 2 misses.

JRJ

On Saturday, June 12, 2021 at 1:50:39 PM UTC-5 michael.s...@gmail.com wrote:

> Hi JRJ,
> thank you for the extensive debugging.
> I've just pushed a new dev release 
> 
> .
>
> Yeah, you're right with the missing timeout. I had assumed the requests 
> library honors the socket timeout configured globally, but apparently not. 
> The standard WeeWX timeout option is now also used for the HTTP requests.
> Additionally, for good measures, I've also added a watchdog for when no 
> packets are received. It has an option to configure the iterations allowed 
> without data. See the changelog for details.
>
> - Michael
>
> cub...@gmail.com schrieb am Freitag, 11. Juni 2021 um 18:13:15 UTC+2:
>
>> I noticed that there is no timeout keyword on the request call 
>> davis_http.request_current.  I will add one to see if it helps.  (I also 
>> note that there is no timeout on the call in start_broadcast either.
>>
>> JRJ
>>
>> On Friday, June 11, 2021 at 10:58:48 AM UTC-5 Jay Jaeger wrote:
>>
>>> I just noticed that the call to _poll_callback()  [to WllPollHost.poll] 
>>> is indeed apparently not returning - noticed in the above logs that there 
>>> is NO message "Polled current conditions".  Working theory: if it receives 
>>> a UDP (broadcast) packet while it is doing the HTTP poll request, the 
>>> driver gets confused.
>>>
>>> On Friday, June 11, 2021 at 10:35:39 AM UTC-5 Jay Jaeger wrote:
>>>

 Happened again while I was looking at logs.  Just for grins, I fired 
 off an HTTP request from my PC, and it woke back up.

 So:  for some reason the WLL driver scheduler _do_tick method call to 
 _poll_callback() never returns, so that _do_tick never returns to 
 _scheduler_tick and thus it goes off to sleepy-land.   QUERY:  Is there 
 some reason it is calling _do_tick() before scheduling the next tick by 
 calling enterabs?  (And no, there is no exception being caught, as far as 
 I 
 can tell.)

 Adding a log.debug call after the _poll_callback() call - but I have no 
 doubt that under these conditions it will not be triggered.

 On Friday, June 11, 2021 at 10:06:10 AM UTC-5 Jay Jaeger wrote:

> Here are some more datapoints from the log that confirm that the 
> needed HTTP request to the WLL box is not occurring:
>
> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: 13scheduler ticks until next push refresh
> Jun 10 22:37:01 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
> 03:37:11 
> Z
> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Scheduler tick
> Jun 10 22:37:11 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Notifying poll callback
> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: 12scheduler ticks until next push refresh
> Jun 10 22:37:12 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
> 03:37:22 
> Z
> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Scheduler tick
> Jun 10 22:37:22 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Notifying poll callback
> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: 11scheduler ticks until next push refresh
> Jun 10 22:37:23 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
> 03:37:33 
> Z
> Jun 10 22:37:33 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Scheduler tick
> Jun 10 22:37:33 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Notifying poll callback
> Jun 10 22:37:34 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: 10scheduler ticks until next push refresh
> Jun 10 22:37:34 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-11 
> 03:37:44 
> Z
> Jun 10 22:37:44 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Scheduler tick
> Jun 10 22:37:44 mythtv2 weewx[239040] DEBUG 
> user.weatherlink_live.scheduler: Notifying poll callback
>
> *** That was the last log message including scheduler
>
> After that we see (excluding most of the .mappers log entries)
>
> Jun 10 22:37:44 mythtv2 weewx[239040] DEBUG urllib3.connectionpool: 
> Starting new HTTP connection (1): va

[weewx-user] Re: weewx stopped for no apparent reason

[Jay Jaeger]

FYI, just had my first case under the new code - worked fine.

Suggestion:  The message logged is the same for both start_broadcast and 
request_current - spotted that when I saw the message and I couldn't tell 
which had failed without looking at the debug log to see the DEBUG entry - 
and even at that I am not 100% certain - if they overlapped?

Here is what got logged (sans the "mapper" entries)

*Jun 15 08:44:10 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-15 13:44:20 
Z*
*Jun 15 13:44:20 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.scheduler: Scheduler tick*
*Jun 15 13:44:20 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.scheduler: Notifying poll callback*
*Jun 15 13:44:20 mythtv2 weewx[297697] DEBUG urllib3.connectionpool: 
Starting new HTTP connection (1): vantagevieww.lan:80*
*Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG urllib3.connectionpool: 
http://vantagevieww.lan:80 "GET /v1/current_conditions HTTP/1.1" 200 None*
Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 25447)
Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG user.weatherlink_live.packets: 
Trying to create UDP conditions packet
*Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.data_host: Received new broadcast packet*
Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Emitting 
push (broadcast) packet
Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG user.weatherlink_live.service: 
WllWindGustService: Updating record with dict: {'windGust': 8.0, 
'windGustDir': 77}
Jun 15 13:44:21 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 25447)
Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG user.weatherlink_live.packets: 
Trying to create UDP conditions packet
*Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.data_host: Received new broadcast packet*
Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Emitting 
push (broadcast) packet
Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG user.weatherlink_live.service: 
WllWindGustService: Updating record with dict: {'windGust': 8.0, 
'windGustDir': 77}
Jun 15 13:44:24 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
*Jun 15 13:44:29 mythtv2 weewx[297697] WARNING user.weatherlink_live: No 
data since 1 iterations*
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 25447)
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG user.weatherlink_live.packets: 
Trying to create UDP conditions packet
*Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.data_host: Received new broadcast packet*
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Emitting 
push (broadcast) packet
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG user.weatherlink_live.service: 
WllWindGustService: Updating record with dict: {'windGust': 8.0, 
'windGustDir': 77}
Jun 15 13:44:29 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
Jun 15 08:44:21 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.scheduler: Next scheduler tick at 2021-06-15 13:44:31 
Z
Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 25447)
Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG user.weatherlink_live.packets: 
Trying to create UDP conditions packet
*Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.data_host: Received new broadcast packet*
Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Emitting 
push (broadcast) packet
Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG user.weatherlink_live.service: 
WllWindGustService: Updating record with dict: {'windGust': 8.0, 
'windGustDir': 77}
Jun 15 13:44:31 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 25447)
Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG user.weatherlink_live.packets: 
Trying to create UDP conditions packet
*Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.data_host: Received new broadcast packet*
Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Emitting 
push (broadcast) packet
Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG user.weatherlink_live.service: 
WllWindGustService: Updating record with dict: {'windGust': 8.0, 
'windGustDir': 77}
Jun 15 13:44:34 mythtv2 weewx[297697] DEBUG user.weatherlink_live: Waiting 
for new packet
Jun 15 13:44:36 mythtv2 weewx[297697] DEBUG 
user.weatherlink_live.davis_broadcast: Received 395 bytes from 
('192.168.42.75', 

Re: [weewx-user] Best air quality sensor for weewx Air-Q

[Karen K]

I now can tell some experiences for the Air-Q device. First impression is, 
that it is a high quality equipment. The company is located at the 
university campus of the Technical University of Chemnitz, and they do some 
research regarding air quality measurement.

The MQTT configuration requires some knowledge in Python, as that 
configuration options are not included in the configuration tool but have 
to applied by an API. The documentation is excellent. But there are 
examples only, how to use the API, and you need to write a short script to 
set the option of your own. "Science" option is needed for that to work.

A simpler approach is to read the value page from the web interface by wget 
or curl, then get the values out of the HTML data by some script and write 
it to a text file, that in turn can be read by WeeWX. No special option is 
needed for that to work.

Smoke/fire detector is included in the device. If activated the device can 
warn in case of smoke or fire by a loud tone. The manufacturer provides 
detailed information about sensor accuracy. 

So I can finally recommend the device.

Karen K schrieb am Dienstag, 18. Mai 2021 um 19:37:01 UTC+2:

> I do not know for sure by now. I plan to purchase one, but I think, it 
> would be possible using weewx-MQTTsubscribe.
>
> weatherl...@gmail.com schrieb am Dienstag, 18. Mai 2021 um 18:01:22 UTC+2:
>
>> Karen,
>>
>> Can WeeWx collect the output of the air-Q units directly via an API?
>>
>> On 23 Apr, 2021, at 05:36, Karen K  wrote:
>>
>> airQ 
>>
>> xsli...@gmail.com schrieb am Freitag, 23. April 2021 um 08:04:22 UTC+2:
>>
>>> Hello,
>>>
>>> I'd like to ask those who already use some air quality sensors connected 
>>> with weewx what is the best option these days. When I check commercial 
>>> weather webs I usually see values PM2.5, PM10, CO, O3, SO2, NO2. Do we have 
>>> some all-in-box solution for these values already? Or it's necessary to 
>>> build it from modules? I saw Arduino has many modules which can be plugged 
>>> but not sure if I have enough time to play with that :)
>>>
>>> Thanks for hints
>>>
>>
>> -- 
>> 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 on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/cb37ed53-23e0-40a2-9ce5-29d8e1e3ce7dn%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/48862391-e374-4071-9726-d9ccc7f06fean%40googlegroups.com.

[weewx-user] Re: Months of missing NOAA reports

[Karen K]

First of all, have a look at the logs. If there are errors, there are 
messages.

Then, if you want help and the messages do not explain it to you, send 
information according to that instruction 
.

Chris Schram schrieb am Dienstag, 15. Juni 2021 um 13:59:51 UTC+2:

> Oops! When my wife just asked me for the total rain from a recent storm,
> I learned that I have not been updating or creating any NOAA reports
> since late February of this year.
>
> That may be the time I replaced my Vantage Vue sensor suite and/or
> replaced my Raspberry Pi with a newer model. At that time I migrated my
> existing database, weewx.conf and slightly tweaked Standard skin, and
> this is the first I've noticed any problem.
>
> I get a 404 error when I try to view the missing data, so that tells me
> It's not being generated at all. Where to I start looking for what I
> screwed up? Thanks.
>
> -- 
> chri...@me.com is a filtered spam magnet. Email replies may be lost.
> You're better off replying to this newsgroup.
>
>

-- 
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/848a2502-a9eb-45c6-9749-e80df41546a2n%40googlegroups.com.

[weewx-user] Re: Belchertown skin - Feels Like Temperature

[Christian Gruber]

that's it, thsw was missing in this file, now its working! 

thanks a lot!

kk44...@gmail.com schrieb am Montag, 14. Juni 2021 um 17:02:14 UTC+2:

> grua schrieb am Montag, 14. Juni 2021 um 14:34:24 UTC+2:
>
>> i have enabled now MQTT, but the thsw temperature isn't showing anymore. 
>> is there anyhting else to adjust for this?
>>
>
> May be, THSW is missing in the template json/weewx_data.json.tmpl
>
> See below and compare to your version of that file.
>
> #encoding UTF-8
> #import datetime
> #errorCatcher Echo
> ## If extended almanac information is available, do extra calculations.
> #if $almanac.hasExtras
>   #set $sun_altitude = $almanac.sun.alt
>   #if $sun_altitude < 0
> #set $sun_None="(%s)" % $obs.label.sun_always_down
> #set $daylight_str = "00:00"
>   #else
> #set $sun_None="(%s)" % $obs.label.sun_always_up
> #set $daylight_str = "24:00"
>   #end if
>   #set $sunrise_ts = $almanac.sun.rise.raw
>   #set $sunset_ts = $almanac.sun.set.raw
>   #if $sunrise_ts and $sunset_ts
> #set $now = $current.dateTime.raw
> #set $today_daylight = $sunset_ts -  $sunrise_ts
> #set $seconds = $today_daylight
> #set $hours = $seconds // 3600
> #set $seconds %= 3600
> #set $minutes = $seconds // 60
> #set $seconds %= 60
> #set $daylight_str = "%d %s, %d %s, %d %s" % ($hours, 
> $obs.label.hour[0] if ( $hours == 1 ) else $obs.label.hour[1], $minutes, 
> $obs.label.minute[0] if ( $minutes == 1 ) else $obs.label.minute[1], 
> $seconds, $obs.label.second[0] if ( $seconds == 1 ) else 
> $obs.label.second[1])
> #set $yesterday = $now - 24*3600
> #set $yesterday_daylight = 
> $almanac($almanac_time=$yesterday).sun.set.raw - 
> $almanac($almanac_time=$yesterday).sun.rise.raw
> #set $difference = $today_daylight - $yesterday_daylight
> #if $difference
>   #set $delta = abs($difference)
>   #set $minute_difference = (int($delta) // 60)
>   #set $minutes_text = $obs.label.minute[0] if ( $minute_difference == 
> 1 ) else $obs.label.minute[1]
>   #set $seconds_text = $obs.label.second[0] if ( int($delta) == 1 ) 
> else $obs.label.second[1]
>   #set $amt_str = "%s%d %s" % (str(int($delta) // 60) + ' ' + 
> $minutes_text + ', ' if ($delta // 60) > 0 else '', $delta % 60 if ($delta 
> // 60) > 0 else $delta, $seconds_text)
>   #if $difference > 0
> #set $delta_str = "%s %s" % ( $amt_str, 
> $obs.label.more_than_yesterday )
>   #else
> #set $delta_str = "%s %s" % ( $amt_str, 
> $obs.label.less_than_yesterday )
>   #end if
>   #set $daylight_str = "%s%s" % ($daylight_str, $delta_str)
> #end if
>   #end if
> #end if
> {
> "site": "$station.location",
> "station_url": "$station.station_url",
> "version": "$station.version",
> "belchertown_version": "$belchertown_version",
> "weewxuptime": "$station.uptime",
> "serveruptime": "$station.os_uptime",
> "serverLocale": "$system_locale",
> "serverLocaleJS": "$system_locale_js",
> "localeEncoding": "$locale_encoding",
> "station": {
> "hardware": "$station.hardware",
> "location": "$station.location",
> "latitude": "$station.latitude[1]' $station.latitude[2]",
> "longitude": "$station.longitude[1]' $station.longitude[2]",
> "latitude_dd": "$station.stn_info.latitude_f",
> "longitude_dd": "$station.stn_info.longitude_f",
> "altitude": "$station.altitude",
> "archive_interval": "#echo $archive_interval_ms / 1000 #",
> "archive_interval_ms": "$archive_interval_ms"
> },
> "extras": {
> "belchertown_theme": "$Extras.theme",
> "theme_toggle_enabled": "$Extras.theme_toggle_enabled",
> "belchertown_locale": "$Extras.belchertown_locale",
> "reload_hook_images": "$Extras.reload_hook_images",
> "reload_images_radar": "$Extras.reload_images_radar",
> "reload_images_hook_asi": "$Extras.reload_images_hook_asi",
> "reload_images_hook_af": "$Extras.reload_images_hook_af",
> "reload_images_hook_as": "$Extras.reload_images_hook_as",
> "reload_images_hook_ac": "$Extras.reload_images_hook_ac",
> "station_observations": "$Extras.station_observations",
> "highcharts_homepage_graphgroup": 
> "$Extras.highcharts_homepage_graphgroup",
> "highcharts_decimal": "$Extras.highcharts_decimal",
> "highcharts_thousands": "$Extras.highcharts_thousands"
> },
> "earthquake": {
> "time": "$earthquake_time",
> "place": "$earthquake_place",
> "latitude": "$earthquake_lat",
> "longitude": "$earthquake_lon",
> "magnitude": "$earthquake_magnitude",
> "url": "$earthquake_url",
> "distance_away": "$earthquake_distance_away",
> "distance_label": "$earthquake_distance_label",
> "bearing": "$earthquake_bearing",
> "bearing_raw": "$earthquake_bearing_raw"
> },
> "station_observations": {
> "current"