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
