When you guys said "downstream consumer" I thought you were referring to us....lol.
On Thursday, 23 February 2017 08:24:29 UTC-5, gjr80 wrote: > > Yes, this 'downstream consumer' does not handle partial packets properly. > It's on the to-do list. > > Gary > > On Thursday, 23 February 2017 23:11:07 UTC+10, mwall wrote: >> >> >> >> 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 >> >
