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/22c3e4f6-59d8-4d8a-a17c-c1866ec6d67fn%40googlegroups.com.
