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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
