Determine source of metric which fails QC

[Joel Baranick]

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.

[Joel Baranick]

BTW, running on Develop

[gjr80]

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

[Joel Baranick]

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?

[gjr80]

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

[Joel Baranick]

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.

[gjr80]

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

[John Kline]

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 <gjrod...@gmail.com> 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

--
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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a8eb1f58-0352-46c4-8b66-905710ea5c54n%40googlegroups.com.

[Joel Baranick]

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.

[Joel Baranick]

I think I have it sorted out now with the changes in this commit: https://github.com/kadaan/weewx-purple/commit/db52c50c9ee4ec92b0357c20ebb8f5fc65f34875

Thanks!!!