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 > <http://weewx.com/docs/customizing.htm#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 [email protected]. For more options, visit https://groups.google.com/d/optout.
