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. -- 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/76E297DD-3D9B-47D7-872C-4F48CB584C4C%40johnkline.com.
