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/8c8e3753-21fd-4f23-8674-ccbe96bf8506n%40googlegroups.com.
