Just a quick question - I have just received my WH57 Ecowitt lightening sensor and was testing to see if I could see the data on my dashboard, but nothing is coming through. I am currently using the WDapi connection at the moment and I noticed in the test module there was no values for lightening - therefore I assume it is currently not included (correct me if I am wrong). If this is the case, would it be as simple as asking Brian to update the WDapi to include lightening information to make it work?
I do have the Ecowitt custom upload working and the lightening data works with this, however my preferred method at this stage is to use WDapi.
I am seeing the lightning detector on my GW1000. Go into WS View and make sure the sensor is showing up in the list of Sensor ID’s and reregister, if necessary. Its working fine here. Absent putting some custom tags in WD, the only place you’ll see on WD’s main page is a tiny little red number near data quality.
I do have the Ecowitt custom upload working and the lightening data works with this, however my preferred method at this stage is to use WDapi.
Thanks,
Neil
The WDapi is, due to its age, rather incomplete. It could have more interesting values to start with.
But f.i. the MB-api has 199 fields, of which large parts are not used.
Same for clientraw.txt , it has 177 fields of which we use less then 40.
There are already two other supported lightning sensors, Nextstorm and WeatherFlow which can be used in parallel with your main station.
I was planning a similar script for GW1000+lighning
But postponed it a few months as the lightning-sensor is not one of the best working parts for now.
It resets itself often to a “no value” state and not only with updating the GW1000 firmware.
My ideas for the “No” answer:
Yes you can ask Brian to include extra fields in the WDapi. Lightning needs only three.
Upload frequency should also be set higher, say 1 /minute minimum.
But what about AirQuality. WeatherDisplay supports Purpleair, GW1000-AQ-sensor and probably more.
Should they not be included in the WD-api?
Other more common sensors such as Extra-temp-hum, soil-moist-temp?
The standard upload file, in your case either WDapi or clientraw.txt should only be used for the most common sensors.
And we should use for the not so often used sensors another format.
That is already available as an extra upload file
=> pwsdashboard.com => Downloads: => The upload-template files when using extra sensor (f.i. soil) can be downloaded
The WD version contains at the bottom the lightning fields:
|lightning|light|%lighteningcountmidnight%|!
|lightningtime|light|--|!
|lightningenergy|light|--|!
|lightningkm|light|--|! // leave as last of the lightning values
So we should ask Brian what the correct tags are for the lightning fields.
Then you can use this upload file to get the extra data. After you removed or set to comment all other lines in the file.
I think an upgrade of the WD-api should at least contain all values of a fully loaded Davis-VP2
That would mean 90% of weather-station owners (regardless of brand of station) could use the WD-api as their only realtime-upload for their templates/dashboard.
If possible due to the increase of the files size, also the todays high-lows and the common used rain-values should be included.
The WD-api should use HTTP-POST because the HTTP_GET length is often restricted by web-hosting companies.
It should have password checking and upload frequency 1 / minute or faster.
For all other high-lows we could use one 5 minute upload-file.
But adapting the WD-api is a lot of work. In the past, I defined multiple WD upload-files while using the WD taglist.txt.
But there is no documentation how to define what data should be in the WD-api as it uses " strange internal" names not the names from the tag-list.
I also doubt how much more users will become a WD user solely based on these enhancements.
i have added lightning count and time to the meteotemplate api
there a number of lightning tags for sure…a lot date back to the 1 wire lightning counter days
some stations now provide time of last strike
and there is a custom tag for that
%lighteningcountlasttime%
interesting about the limit on HTTP get
what could be an option is to use a custom template for the raw data provided for WD API
based on custom tags…
i.e it would be by default what is provided now…but because its customizable it means things could be taken away or added (custom tags)
?
I was just looking into this a bit more from and what I can tell WD would pass the time/date of the last lightening strike as a string, whereas I think the dashboard would be looking for the the epoch/unix time - is that correct? If this is the case is there a way to make this work on the dashboard?
As a PHP programmer I prefer unix time stamps. But that is nearly never the case.
Any string is OK as long as it contains the date and time.
F.I. a last trike time only, could generate a popup notification based on the time of the yesterday strike.
I can make it available as Unix time as a different tag (i.e a number…a very big number)…some weather stations its provided as unix time in the first place
