Option 3 was implemented in v0.2.3. No need to do anything with appTemp, rtgd taes care of it.
Gary On Monday, 20 February 2017 06:05:34 UTC+10, tempus wrote: > > Your Option 3 below seems best to me. Where is the best place to set > apptempL and apptempH both to the current appTemp value? > > 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.