Everything in weewx using the WF driver is based on what you mapped to what in weewx.conf, if you mapped it at all. I skipped lightning in my setup because it’s inaccurate and we get ‘very’ little lightning around here anywhere.
1 Like
I’m with @vinceskahan in also not ever configuring it to save in WeeWX, since I don’t need the historic data.
Did you extend the WeeWX database schema to hold lightning data? There was no WeeWX support for storing lightning data out of the box the last time that I looked.
With that said, I strongly suggest that anyone trying to store lightning data use their search engine du jour and find the article about extending the WeeWX schema for supporting the Franklin AS3935. This is the same chip that WF uses in the Air, and using the same database field names will make any future custom reports compatible between the Air and generic AS3935 driver users…
1 Like
Thanks for the comments - i did not realise Weewx did not support lighting out of the box, as its mapped as part of the driver - ie lightning_strikes = lightning_strike_count.AR-00003549.obs_air I kind of assumed it was being written to the database.
I will take a look at extending and looking at the AS3935 seems to get me in the right direction 
Will let you know if i get it working… thanks as ever for the pointers,
Andy
1 Like
It s a still todo for @vreihen weatherflow-udp/todo at master · captain-coredump/weatherflow-udp · GitHub
I m still waiting 
1 Like
Perhaps you should double or triple what you paid him for the nice driver he wrote out of the goodness of his heart…
He asked no donations for himself but for charity you ve no idea how much i donate for charity.
I m very happy he wrote the driver.
2 Likes
Yes indeed, extending the database on my own WeeWX instance and then adding the instructions to the readme file are still on the todo.
Since then, I was drafted to write a UDP driver for the Atmocom interceptor device. I forked the WF driver, and took the liberty to add all of the features that I would like to see in v2.0 of the WF driver (like automatically building a base sensor_map using the WeeWX config tools). Those improvements now need to be back-ported to the WF driver, which I have been putting off since @dsj has teased possible UDP packet changes that may require changing the parsing tables in the driver.
Anyway, if someone wants to contribute instructions for extending the WeeWX database schema that work for both MySQL and sqlite, I will gladly add them to the readme file for everyone else to use. (FYI, I work in academia, and this is a crazy time of year at work for me…)
3 Likes
Thanks for your feedback. I hadn t thougt of the issues atm.
I didnt know you did write another driver.
I made my comment with solarglasses, i d better used a wink.
Unfortunally i m not a programmer, date and time should be fine too in a readeable format intstead epochtime.
I know work comes first. Anyway thanks for your efforts 
The only potential change would be extending the length of the ob[] array, and we have no immediate plans to do that - we likely won’t do that until it needs to be done (due to the addition of a parameter, for example), and there is no need currently envisioned. Regardless, as long as the driver can handle an arbitrary-length array, that particular future change shouldn’t break it anyway.
1 Like
The driver has a whole Python dictionary dedicated to mapping ob/obs array data fields into usable names. Here is the entry for obs_air as an example:
fields['obs_air'] = ('time_epoch', 'station_pressure', 'air_temperature', 'relative_humidity', 'lightning_strike_count', 'lightning_strike_avg_distance', 'battery', 'report_interval')
Adding new fields to the ob/obs arrays is probably not going to break anything, although the new field data will not be available until the dictionary is updated with the new names. Re-ordering the fields will be a problem though…until the order is swapped in the driver’s dictionary to match the new UDP array(s).
I cringe thinking about the possibility of a new format UDP packet being rolled out to the field testers, and having to support both at the same time until everyone else’s Hubs are up to the same revision. Guess the correct fix is to make the dictionary also have provisions for checking the Hub firmware version being used (or even better requesting the addition of a JSON API version field to each packet), so that it can automagically adjust should there ever be a time with multiple ob/obs array formats in use.
Of course, if the UDP packets were all in native JSON and not positionally-coded ob/obs arrays, absolutely nothing would need to be changed at the driver level… 
2 Likes
Right! Python will just ignore any elements beyond report_interval
Right! But we won’t do that!
4 Likes
I forgot to mention that the driver re-write will also include Python v3 compatibility, which will be needed for WeeWX 3.x. The Python 3 compatibility tests flag some likely problems, which are all in sections of the code that I want to re-write anyway…
1 Like
Hello there, do you have the modified Belchertown skin code? I just got the 10 inch fire and wanted avast up just like yours.
Thanks
I hacked up a pre-release version, which is grossly obsolete. The only major change that I recall was hiding the top banner, since I (hope!) that I know where my station is and wanted to use that screen real estate for actual data.
You would be surprised at how much you can do by just tinkering with the zoom and font size values in the Fully Kiosk Browser’s settings. The responsive library that POB used for the Belchertown skin does a pretty good job at making the page look good as you tinker with these settings…
Did you get lightning to report? I added it to the weewx database but I am getting strange data.
sum Strike_count : 16.8
Avg_distance: 2.2mi
I am using these for the values:
lightning_strikes = lightning_strike_count.AR-00004444.obs_air
avg_distance = lightning_strike_avg_distance.AR-00004444.obs_air
Thanks I got a fire HD 10 and it works perfect with the skin and Fully Kiosk Browser.
1 Like
I didnt get round to it in the end - looks like your almost there - i would post on the weewx google group as they are really responsive and you should be able to solve things.
Do let me know if you get it working!
Andy
1 Like
I hope this is the right place to ask. In my plot I show the maxSolarRad and the solar radiation reading from the Sky. There is a difference in the max value which I compensate later. But I see the head and tail start earlier/finish later than the theoretical one. This is really fine tuning, not a real issue.
Is there a way to compensate this or ?
I use this data to calculate sky condition. I’d like to add sunshine hours calculation.
1 Like
Just an update for others - I just sent @vreihen the patches to get the existing driver working under python3 versus the new weewx 4.0 alpha.
Also a minor correction, the coming weewx 4.x (not 3.x) does not require python3, it supports both python2 and python3.
5 Likes
I just pushed out a new version (1.10) to GitHub:
https://github.com/captain-coredump/weatherflow-udp
The biggest change is adding support for the new Tempest Weather Station.
Other changes are WeeWX 4.x support, and running under Python 3.
*** Note that this version is hard-coded for Python 3. See the changelog for lines that need to be edited to run under Python2.
Disclaimer - My testing Raspberry Pi 4 had to be re-purposed due to an unexpected home automation emergency, so I have not performed my usual QA testing before releasing this. (Thanks to COVID-geddon, it takes 2+ weeks to get something as simple as a new Pi when I could have it in my hands in two days before.) If someone has a running WeeWX Python 2 test instance and can verify that the changelog edits work, it would be most appreciated.
(@vinceskahan - I’ve finally broken down and started building Docker containers for all of my home stuff, starting with my home automation HomeBridge gateway. WeeWX 4.x production/test will be next!)
Be safe and stay healthy…
4 Likes