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.
