To wrap this one up, I'm good to go. I'm using a fork of another driver, and the station data gets processed through 2 functions before it's yielded. If the packet is <= 1 then it's discarded. Well in my testing I was only providing 1 observation of data so the packet was only a length of 1 which is why it never showed up - it was discarded. So I overlooked that conditional for quite some time, but anyways, thanks again!
On Tuesday, April 16, 2019 at 8:02:17 PM UTC-4, gjr80 wrote: > > Yes, get the data flow working then worry about the niceties later. > > Gary > > On Wednesday, 17 April 2019 09:55:39 UTC+10, Pat wrote: >> >> That's what I was assuming as well - which made me think maybe this >> wasn't supported. >> >> I'm digging in further and using a lot of prints to follow the flow. At >> some point it seems the key is stripped off and I haven't figured out why >> yet. But this is helpful knowing that it's at least possible. >> >> >> >> On Tuesday, April 16, 2019 at 7:23:59 PM UTC-4, gjr80 wrote: >>> >>> If it's not appearing in LOOP then it will not appear in REC, so I guess >>> you need to have a look again at your driver and make sure it is actually >>> emitting it (remember what you see on the console is from StdPrint >>> after all the processing of the packets/records occur so it may be >>> different to what is actually coming out of the driver - unusual for things >>> to disappear though). >>> >>> Gary >>> >>> On Wednesday, 17 April 2019 09:19:36 UTC+10, Pat wrote: >>>> >>>> Hi Gary, >>>> >>>> Understood on the debate. Since I'm able to include it into my station >>>> data source, it makes sense and is quick work to include it in the driver. >>>> >>>> When I run weewxd /etc/weewx/weewx.conf, there is no lightning_distance >>>> in the LOOP and no lightning_distance in the REC. So I must be missing >>>> something? >>>> >>>> On Tuesday, April 16, 2019 at 7:12:38 PM UTC-4, gjr80 wrote: >>>>> >>>>> Hi Pat, >>>>> >>>>> So your driver is picking up the distance data, adding it to a field >>>>> called lightning_distance and emitting it in a loop packet. If it's >>>>> numeric (is it?) WeeWX should certainly be accumulating it and including >>>>> it >>>>> in archive records, there is nothing more to do other than selecting the >>>>> correct extractor function, though the default is average so that should >>>>> be >>>>> fine. As for the driver, the driver is just a driver, it doesn't care >>>>> where >>>>> the data comes from or how it got there, if it's there and available its >>>>> just data. There maybe a debate to be had about whether you are making a >>>>> driver too complex by adding data from multiple sources but that is not >>>>> the >>>>> issue here by the sounds of it. >>>>> >>>>> So you are running WeeWX directly and see lightning_distance in LOOP: >>>>> but not in REC: or does it appear as None ? >>>>> >>>>> Gary >>>>> >>>>> On Wednesday, 17 April 2019 08:24:17 UTC+10, Pat wrote: >>>>>> >>>>>> I'm working on adding an AS3935 lightning sensor to my Davis VP2 >>>>>> station setup as an external sensor. My weewx driver is a customized >>>>>> socket >>>>>> server driver, so I'm able to inject this lightning data to the socket >>>>>> so >>>>>> the driver picks it up right away with the LOOP. >>>>>> >>>>>> I've read matthew's service for this sensor >>>>>> <https://github.com/weewx/weewx/wiki/as3935>, but I don't think that >>>>>> it applies to my setup since I'm not hooking the AS3935 to a Raspberry >>>>>> Pi >>>>>> GPIO. >>>>>> >>>>>> I've extended my schema to have "lightning_distance" in the archive >>>>>> table. >>>>>> >>>>>> I was hoping that yielding a key of "lightning_distance" to the LOOP >>>>>> packet (e.g. packet["lightning_distance"]), that it would be stored >>>>>> in the loop and sent to the archive on REC. This seems to not be the >>>>>> case - >>>>>> which I kind-of expected. >>>>>> >>>>>> A custom service could be challenging since this data would be >>>>>> delivered directly to the driver. >>>>>> >>>>>> So my question; is it possible to have my driver yield custom >>>>>> variables to the LOOP so it can be processed - or do I have to do a >>>>>> custom >>>>>> service? Or can the driver send the data to a custom service? >>>>>> >>>>>> Looking for some thoughts and insight on best practice. >>>>>> >>>>>> Thanks! >>>>>> >>>>>>
