I think I have it sorted out now with the changes in this commit: https://github.com/kadaan/weewx-purple/commit/db52c50c9ee4ec92b0357c20ebb8f5fc65f34875
Thanks!!! On Friday, December 17, 2021 at 8:18:10 AM UTC-8 Joel Baranick wrote: > Hey John. Nope, it does not. I included it in a fork and it worked for a > long time. The weewx server died and had to be rebuilt from scratch. > After that, it is no longer working. > > On Friday, December 17, 2021 at 5:51:28 AM UTC-8 [email protected] > wrote: > >> Hi Joel, >> >> The purple extension does NOT insert pressure into the loop packet. You >> can see that for yourself if you look at new_loop_packet in the plugin. >> Are you modifying the extension to add it? >> >> On Dec 17, 2021, at 2:49 AM, gjr80 <[email protected]> wrote: >> >> There are many ways to handle unit conversion, some more sophisticated >> than others. Here are a couple of fairly basic approaches >> https://github.com/matthewwall/weewx-maxbotix/blob/master/bin/user/maxbotix.py#L142 >> >> and >> https://gitlab.com/wjcarpenter/bme280wx/-/blob/master/bin/user/bme280wx.py#L82 >> >> >> Gary >> >> On Friday, 17 December 2021 at 20:30:03 UTC+10 [email protected] wrote: >> >>> Thanks! You mind pointing me at a reference implementation of a service >>> class that does this all correctly? I'm likely able to get it working on >>> my own if I see how it is to be done. >>> >>> On Friday, December 17, 2021 at 2:11:13 AM UTC-8 gjr80 wrote: >>> >>>> Any values have to be analysed in context of the unit system of the >>>> packet into which they are inserted. The unit system of packets emitted by >>>> the sdr driver when reading acurite devices is either US customary or >>>> metric depending on the sensors being read. As far as I can tell the >>>> purple >>>> air extension you are using does not perform any check of the unit system >>>> of the loop packet (loop packet field usUnits) to which pressure is added, >>>> but I could be wrong. Normally you would find something in the method of >>>> the service class that is bound to the NEW_LOOP_PACKET event (in this case >>>> Purple.new_loop_packet()) that checks usUnits and converts pressures, >>>> temperature, speeds etc to match the packet units. Or if not in that >>>> method >>>> in the code called by that method. >>>> >>>> I’m not about to try to debug someone else’s extension, especially one >>>> as complex as this. John, the author, frequents the forums so give it a >>>> day >>>> or so and see if he comments. Otherwise I suggest you raise an issue in >>>> his >>>> repo. >>>> >>>> Gary >>>> >>>> On Friday, 17 December 2021 at 19:16:38 UTC+10 [email protected] wrote: >>>> >>>>> Well, I have basically two sources: acurite sensors via sdr and the >>>>> purple api via a purple api plugin. The acurite sensors don't expose >>>>> pressure and the rtl433 logs never indicate that a pressure is detected >>>>> in >>>>> the acurite information. >>>>> >>>>> The purple api does expose pressure and it comes in as millibars: >>>>> 200 success { "api_version" : "V1.0.10-0.0.12", "time_stamp" : >>>>> 1639725648, "data_time_stamp" : 1639725596, "sensor" : { >>>>> "sensor_index" : 81961, "pressure" : 1018.5 } } >>>>> >>>>> That said there are log lines that indicate the pressure was read from >>>>> purple and included as inHg in the result. >>>>> >>>>> weewx[1] DEBUG user.purple: Inserted packet[pressure]: 30.096963 into >>>>> packet. >>>>> >>>>> I've run the purple plugin locally and verified that is is converted >>>>> to inHg. The conversion happens here: >>>>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L266. >>>>> >>>>> Is this the proper way of doing it? If not, can you point me to an >>>>> example >>>>> of doing it properly in a plugin? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Friday, December 17, 2021 at 12:39:29 AM UTC-8 gjr80 wrote: >>>>> >>>>>> What driver are you using and what is the source of the pressure >>>>>> value? This sounds very much like a service is being used to add one or >>>>>> more of the three pressure fields (altimeter, barometer or pressure) to >>>>>> packets/records from the driver and the unit system of the packet/record >>>>>> is >>>>>> not being checked and followed. This can result in fields being added to >>>>>> packets/records in the wrong units which eventually results in a double >>>>>> unit conversion. >>>>>> >>>>>> The answer will almost certainly be related to the source of one of >>>>>> the three pressure fields. >>>>>> >>>>>> Gary >>>>>> On Friday, 17 December 2021 at 17:56:10 UTC+10 [email protected] >>>>>> wrote: >>>>>> >>>>>>> BTW, running on Develop >>>>>>> >>>>>>> On Thursday, December 16, 2021 at 11:54:46 PM UTC-8 Joel Baranick >>>>>>> wrote: >>>>>>> >>>>>>>> What is the best way to determine the source of a metric which >>>>>>>> fails QC? The failure in this case is the "pressure" metrics which is >>>>>>>> expected to be in inHq. The QC error is: `LOOP value 'pressure' >>>>>>>> 0.8885885448234093 outside limits (24.0, 34.5)`. It seems like the >>>>>>>> pressure is converted to inHq correctly: `Inserted packet[pressure]: >>>>>>>> 30.091057 into packet.`. But, it seems like the 30.091057 is being be >>>>>>>> fed >>>>>>>> back into the conversion function. >>>>>>> >>>>>>> -- >> 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/a8eb1f58-0352-46c4-8b66-905710ea5c54n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/a8eb1f58-0352-46c4-8b66-905710ea5c54n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/4a6166aa-fb15-44ae-a05c-f93a06a38c12n%40googlegroups.com.
