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/336fc85c-8c81-4f4c-9697-5d86e88ea20bn%40googlegroups.com.
