On Thursday, February 23, 2017 at 7:59:13 AM UTC-5, Bill Morrow wrote:
>
> I discovered a possible problem with this approach working well with other 
> parts of weewx. Last night I was attempting to get the Realtime Gauge-Data (
> https://github.com/gjr80/weewx-realtime_gauge-data) extension going, and 
> ran in to a problem because not each packet the my wxMesh driver subscribes 
> to has the same data. Here, an indoor station packet arrives, is parsed and 
> the temperature (INTE) and humidity (INHU) yielded to weewx, which causes 
> rtgd to do some work. rtgdthread exits on a KeyError, because the packet 
> does not contain outTemp. 
>
> The opposite can also happen, if an outdoor packet arrives, rtgdthread 
> will exit because if cannot find the inTemp keyword.
> ...
> Should the wxMesh driver set all possible data to None before parsing the 
> incoming MQTT message? Or is this a problem for rtgdthread to deal with? Or 
> StdWXCalculate in weewx?
>
> I'm asking not so much for these two specific modules, but as a general 
> design guideline for my driver.
>

partial packets are ok - the driver should emit data as soon as it receives 
data, and only for observations that it actually knows about.

so do not fill a loop packet with a bunch of None values - use None only to 
indicate that the observation returned a bogus value, not to indicate that 
the driver is capable of returning that value but just happened to not 
return a value for that sensor this time around.

you will find many downstream consumers that do not handle partial packets 
properly.  that is a bug in the downstream consumer, and the downstream 
consumer needs to be fixed.

m 

Reply via email to