crt extension has been updated

[mwall]

the cumulus realtime (crt) extension has been around awhile, but recently received a major update:

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

this extension should make it trivial to use weewx with any weather template that gets its data from a cumulus 'realtime.txt' file.  that includes meteotemplate, leuven, saratoga, and weatherbyyou.

thanks to gary for extensive testing.

we thought about an extension that would output weather display 'customXXX' files, but pretty much anything that works with wd customXXX works with cumulus realtime.

from the changelog:

0.18 10apr2016
* graceful recovery when no forecast binding defined
* refactor unit conversions to support per-observation unit specifications
* more fixes from gary for better unit conversions and cumulus compliance

0.17 28mar2016
* lots of fixes from gary roderick:
* Introduced StrictVersion to more easily compare weewx version numbers.
* crt now requires weewx 3.2.0 or later.
* Fixed UNITS_RAIN typo, weewx rain unit is 'inch' not 'in'.
* Added UNITS_ALT to facilitate cloudbase units lookup.
* Replaced knottoBeaufort() with call to weewx.wxformulas.beaufort().
* cloudbase, maxSolarRad, humidex, appTemp and heatindex are now included in
  weewx loop packets so removed manual calculations of these obs.
* Side benefit of using maxSolarRad from loop packet means crt no longer
  crashes if pyephem is not installed.
* Reworked calcDaylightHours() to use Almanac objects
  rather than Sun object calcs so that additional accuracy of pyephem can be
  taken advantage of if installed.
* Weewx is now windrun aware though windrun is not included in loop packets.
* Reworked windrun unit conversions to make use of weewx API.
* Sunshine hours calculations remain flawed but it now uses an Almanac
  object as the basis for its calculation.
* radiation had no formatting applied resulting in numerous decimal places
  in realtime.txt, reduced that to 1 decimal place (probably only an issue
  with simulator).
* Minor changes to some packet names to reflect new fields now in weewx loop
  packet eg cloud_base v cloudbase.
* Found that crt would fail if used with an empty archive (could not get db
  US units to do conversion so _cvt() method would cause a failure). Was a
  vicious circle; if used with an empty archive crt would cause weewx to fail
  and because weewx failed you could never get any records into the archive.
  The only work around was to not install/run crt on an empty archive. I
  reworked the _cvt() method to return None is the archive has no records,
  gives a lot of NULLs in the output until you get records in the archive then
  it operates as normal.
* Did some further comparison of Cumulus realtime.txt wiki page and Cumulus
  Webtags wiki page. By cross referencing the Webtags between the wiki pages
  it was possible to confirm details of a number of realtime.txt fields:
   - field 6 (wind avg speed)and field 47 (wind avg dir). Averaging period is
     not mentioned directly although the corresponding Webtags use 10 minute
     averages by default. This confirms current crt settings.
   - field 52 (avg_wind_dir). This is the compass direction of the 10 min
     average wind bearing, changed code to reflect this.
   - Cumulus uses wind direction of 0+ to 360 with 0 indicating calm.
* Reworked calcAvgWindDir() and calc10MinAvgWindDir() to return None or
  0+ to 360 rather than None or 0 to 360-.
* Given the way Cumulus represents wind direction introduced
  data['cumulus_windDir'] mainly to differentiate from/not overwrite
  data['windDir']
* Confirmed that month and year rain are month to date and year to date
  values from 1st of month and year respectively. Removed 2 related FIXME
  comments.
* field 11 is listed as in the realtime.txt wiki page as 'barometer (The
  sea level pressure)' with the equivalent webtag of #press. #press is listed
  in the webtags wiki page as 'The sea level pressure'. These are completely
  consistent with using weewx 'barometer'. Removed the comment re uncertainty
  over what pressure is specified in realtime.txt.
* Observed a number of real world live realtime.txt files and confirmed that:
   - realtime.txt uses local time. Reworked date/time to use local time
     throughout.
   - None/NULL handling is not specified in Cumulus realtime.txt wiki but
     observation of a number of realtime sites showed that when there is no
     wind, wind speeds are set to 0 not NULL. Introduced 'none' setting in
     weewx.conf    [CumulusRealTime] to allow user specification of what
     character/sequence of
     characters will be displayed in place of 'None' values in realtime.txt.
     Default setting is NULL.
   - Confirmed that Cumulus replaces compass points with '---' if it is
     calm/no wind. Implemented this via change to format()

0.16 27feb2016
* fix 'is sunny'

0.15 12feb2016
* include zambretti forecast if forecast extension is installed

0.14 14oct2015
* update readme with weewx 3.x instructions

[Chotechai Piyavongsiri]

mwall...thanks a lot for this useful extensions. Do you have any idea about producing a realmore.txt file mentioned in this forum?

http://sandaysoft.com/forum/viewtopic.php?f=26&t=16398

[mwall]

On Thursday, December 28, 2017 at 10:25:18 PM UTC-5, Chotechai Piyavongsiri wrote:

mwall...thanks a lot for this useful extensions. Do you have any idea about producing a realmore.txt file mentioned in this forum?

http://sandaysoft.com/forum/viewtopic.php?f=26&t=16398

hello chotechai!

this is the first time i've heard of 'realmore.txt'

apparently it contains:

<#pressYL> <#TpressYL> <#pressYH> <#TpressYH> <#pressTL> <#TpressTL> <#pressTH>


<#TpressTH> <#WindRoseData> <#realtimeinterval> 

if you can provide a definition for each field (we need to know the set of possible units for each field too!) as well as at least one example of actual output for each field (a few sample realmore.txt files would be best), then we might be able to add 'realmore.txt' to the list of files output by the weewx-crt extension.

m

[gjr80]

Just look like standard Cumulus web tags to me (http://wiki.sandaysoft.com/a/Webtags).

Gary

[mwall]

On Thursday, December 28, 2017 at 11:05:22 PM UTC-5, gjr80 wrote:

Just look like standard Cumulus web tags to me (http://wiki.sandaysoft.com/a/Webtags).

Gary

right you are, gary!  but i'm still not clear what cumulus wind rose data actually look like.  examples would help, with corner cases.

imho, the weewx-crt extension is getting a bit too complicated.  it would be better if there were a CumulusWebTagsEngine that could be used in a weewx-crt extension to emit the realtime.txt, realmore.txt, and whatever else someone might create that emits cumulus web tags.  and it could also be used in a CumulusGenerator that could be used like CheetahGenerator but with cumulus syntax instead of cheetah syntax.

as a quick way to do what chote wants, maybe use CheetahGenerator to emit the realmore.txt (since once per archive interval should be fast enough for those data), and the weewx-crt extension to emit the realtime.txt (since those can be LOOP and emitted much more frequently).

m

[gjr80]

I did a bit of digging/googling/reading between the lines when I was putting together an extension to produce a loop based gauge-data.txt for the SteelSeries gauges and worked out the format of the windrose 'field' (realtime.txt and gauge-data.txt use the same Cumulus windrose web tag). From memory it is simply the sum of the wind speeds for each of the 16 cardinal/intercardinal/secondary intercardinal directions over a period of time. A fairly straightforward sql query and a bit of processing of the query results gives the required data. Units are irrelevant since all you are concerned with is the relative values. My implementation is in def calc_windrose() in rtgd.py (https://github.com/gjr80/weewx-realtime_gauge-data/blob/master/bin/user/rtgd.py)

Don't see why a simple template could not be used for realmore.txt, there is nothing complex about it and one of the linked docs says 'does not require an update in realtime, just every few minutes' so a cheetah template would do fine.

CumulusWebTagsEngine and CumulusGenerator, maybe next months job, unless you have one ready to go Matthew?

Gary

[Chotechai Piyavongsiri]

Mathew, Gary...thanks a lot....

[Chotechai Piyavongsiri]

Hi Matthew,

Just have time to dig deeper on the realmore.txt content. I attach its sample  content and my interpretation for your view. I also put the wind direction raw data in Excel and use the graph function to produce the wind rose. It matches the wind rose produced by other javascript function. I’m not sure you should extend your function to produce the realmore file. Pls consider.

On Tuesday, 23 January 2018 12:21:42 UTC+7, Chotechai Piyavongsiri wrote:

Mathew, Gary...thanks a lot....

[Chotechai Piyavongsiri]

The bigger screenshot is here: Realmore.txt raw data and wind rose

[Chotechai Piyavongsiri]

Hi Matt....any chance you could help to add realmore.txt file?...thanks