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!
>
>

Reply via email to