Great, I look forward to seeing it Sent from my iPhone
> On 28 May 2019, at 07:34, Jd D <[email protected]> wrote: > > Hi Ian, > > Using the data itself will make the system more stable since it has a lower > chance of get changed by accident. I already created a javascript file in js > folder so the function does not have to be included in all the files just the > function call. I will update the other graphs and do some testing and then > send these changes to you. Also did you know that adding zoomEnabled : true > allows the user to zoom into the graphs. I use that option on all my graphs. > > One other side note I have the latest template working on weewx 3.8.2 So far > only a couple minor changes to the w34stats template and new two line > function in units.py > Take care > Jerry > >> On Monday, May 27, 2019 at 11:26:02 PM UTC-7, steeple ian wrote: >> Hi Jerry, >> >> Believe it or not there is a Jake that I am in discussion with on weather >> matters, just not around this forum! >> >> I thought it might be the case that you are using your CRT for other >> purposes. >> >> I am very open to look at more efficient ways of doing things. At the moment >> the process is to mirror how MB does it under the bonnet. The guiding >> principle should be that the user experience is identical and stays faithful >> to the existing visual design, now and in the future. If this can be >> achieved whilst being easy to maintain and speedily react to changes to the >> parent. >> It does seem what you are suggesting might benefit the other versions so it >> could be a win-win situation all round. >> >> So that’s the challenge! >> >> Regards, >> Ian >> >> Sent from my iPad >> >>> On 28 May 2019, at 03:53, Jd D <[email protected]> wrote: >>> >>> Hi Ian, >>> No problem with the name been called a lot worst in the past. :-) >>> I do have a suggestion for the displaying and graphing of different units >>> that I have tested. But first I like to explain my reasons for doing >>> something different. Right now I am using US units with a device that is >>> sending US unit data. To do it the current way (which I still see issues >>> with) the system would have to convert the F data in the database to C and >>> then back to F when I display it. From a CS point of view these types of >>> operations really should be avoided. Also I am using the CRT data for other >>> systems which means I would have to convert the data for those systems. To >>> me the biggest reason I do not like the current approach is the data is in >>> the database with its "native" units. Just by adding $unit.label.outTemp to >>> the result template and now I know the units of the data where ever I use >>> it. Then all I needed was a three line javascript function to compare the >>> units of the data with the units I am displaying and decide if a conversion >>> is needed. For me this removes three conversions of the data and works for >>> both C and F settings of the template. I can send you what I have if it >>> would help understand what I am getting at. I still need to send you my >>> other changes but I am making sure I have not missing anything. >>> Thanks >>> Jake aka Jerry >>> >>>> On Monday, May 27, 2019 at 5:43:58 PM UTC-7, steeple ian wrote: >>>> Whoops, >>>> >>>> Sorry Jerry, this was meant for you not Jake. >>>> >>>> Ian >>>> >>>>> On 27 May 2019, at 23:01, steeple ian <[email protected]> wrote: >>>>> >>>>> Hi Jake, >>>>> >>>>> I now see what is happening and the reason that you are having to change >>>>> things when they relate to non metric units. >>>>> >>>>> The template is designed to receive realtime data in metric units. One of >>>>> the early roots for this template was based on Cumulus realtime.txt, >>>>> which by default emits metric units, that is why the CRT extension should >>>>> be set for METRIC in the weewx.conf file (as per the snippet in the >>>>> install guide. Unless, of course you are also using CRT for an additional >>>>> purpose which requires US units). Give it a try with the original files >>>>> and see what happens. >>>>> >>>>> I will update the instructions to emphasise this important point. >>>>> >>>>> Regarding the dew point graphs appearing instead of rainfall, I did >>>>> exactly as you suggested. I realised what happened when I was updating >>>>> the charts for another purpose 3 days ago and I fixed them at the same >>>>> time. >>>>> >>>>> Regards Ian >>>>> >>>>>> On 27 May 2019, at 19:22, Jd D <[email protected]> wrote: >>>>>> >>>>>> Hi Ian, >>>>>> >>>>>> It is set to >>>>>> unit_system = US >>>>>> >>>>>> Also a couple chart items. >>>>>> 1) Yearly and Monthly rainfall charts are dew point charts in your >>>>>> release. Looks like something got overwritten or renamed. The file names >>>>>> are correct just the code inside does not match the file name. >>>>>> >>>>>> 2) Also had to comment out the conv code for the barometer charts so the >>>>>> charts matched my units inHg. >>>>>> >>>>>> Thanks Jerry >>>>>> >>>>>>> On Monday, May 27, 2019 at 11:11:23 AM UTC-7, steeple ian wrote: >>>>>>> Jerry, >>>>>>> >>>>>>> Can I just check, have you got realtime.txt set for US units or METRIC >>>>>>> units in your weewx.conf file? >>>>>>> >>>>>>>> On Mon, May 27, 2019 at 6:09 PM steeple ian <[email protected]> wrote: >>>>>>>> Hi Jerry, >>>>>>>> That’s excellent information. I will be very interested to have a copy >>>>>>>> of the livedata and other file changes when you have completed them. >>>>>>>> Thank you very much, >>>>>>>> Ian >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On 27 May 2019, at 17:53, Jd D <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Ian, >>>>>>>>> >>>>>>>>> Here are a couple more. The following code exists in multiple graphs >>>>>>>>> and causes the graphs to be messed up since the data is already >>>>>>>>> Fahrenheit . Not sure why this was needed at all. I commented it out >>>>>>>>> to fixed the graphs >>>>>>>>> .// if ($tempunit == 'F') { >>>>>>>>> // $conv = '(9 / 5) + 32'; >>>>>>>>> // } else { >>>>>>>>> $conv = '1'; >>>>>>>>> // } >>>>>>>>> >>>>>>>>> Also in shared.php looks like a cut and paste error deleted most of >>>>>>>>> the code for function anyToF. The bold text below was what I added. >>>>>>>>> >>>>>>>>> function anyToF($field){ >>>>>>>>> global $weather; >>>>>>>>> if ($weather["temp_units"] == 'F'){ >>>>>>>>> return $field; >>>>>>>>> } else { >>>>>>>>> >>>>>>>>> return cToFDirect ($field); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> In barometer.php there is a hard coded 100 in a for loop that blows >>>>>>>>> up. I changed it to be the sizeof the array. >>>>>>>>> for ($i = 0; $i < sizeof($parsed_json); $i++) { >>>>>>>>> $magnitude[$i]=$parsed_json{$i}{'magnitude'};$eqtitle[$i]=$parsed_json{$i}['title'];$depth[$i]=$parsed_json{$i}['depth'];$time[$i]=$parsed_json{$i}['date_time']; >>>>>>>>> >>>>>>>>> In livedata.php I made a number of changes to handle when the data >>>>>>>>> was not as expected. Like if the time value was a string instead of a >>>>>>>>> integer. I just put a (int) in front of the variable so that it would >>>>>>>>> work for both string and integer values. Did the same for float for >>>>>>>>> wind speed. Also there were a number of places where N/A was used >>>>>>>>> when data did not exists and then those variables where used in a >>>>>>>>> number format function which then errors out. I just check to see if >>>>>>>>> the variable is_numeric before calling the number format function. I >>>>>>>>> will send you my livedata.php and other files that I have changed >>>>>>>>> when I am all done if you like. >>>>>>>>> >>>>>>>>> I still see few more things that do not look right that I still need >>>>>>>>> to track down. >>>>>>>>> Take care >>>>>>>>> Jerry >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/weewx-user/271661a7-066c-40ae-a6c9-40c622b1faed%40googlegroups.com. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> -- >>>>>> 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]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/weewx-user/cdf8a5f6-1543-449b-97ee-8cf564168fcf%40googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>> >>> -- >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/weewx-user/e6a18732-cbe4-446e-8363-c6e2d4d63ed9%40googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/cec657f2-c304-4220-ab65-3a86b7642feb%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/6671F178-26E3-4AFC-87A1-32301ED8D5CA%40gmail.com. For more options, visit https://groups.google.com/d/optout.
