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 approa
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 goi
Hi Bill,
Not sure it helps, but I output some loop packet of my Oregon station
(WMRS200 using WMR100 driver provided with weewx:
LOOP: 2017-02-22 12:33:40 CET (1487763220) altimeter: None, appTemp: None,
barometer: None, cloudbase: None, dateTime:
1487763220, dewpoint: None, heatindex: None, h
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 subscri
