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

Reply via email to