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.

Reply via email to