GW1000 + WH57 lightning sensor only - Lightning not showing in MB. **unsolved**

[Gyvate]

you've got a reply

[Gyvate]

we'll take it offline from here and see what the testing provides.
Will post the results.
Suggestions from the community are still welcome

[Gyvate]

It appears that @Wim was holding his nose in the right direction ...

tests copying @woolfg's setup show that the logger in MB (Pro) does not detect the sensor even though it is present and even though the GW1000 sends the related data. The time stamp of the last strike and the distance of the last strike can be retrieved from the GW1000.
The lgt0xxx sensors are not visible in the mapping, cannot be chosen and lightning doesn't appear neither in the sensor raw data nor in the min/max history.

The data appear in the WSView app which uses the GW1000 API, hence no defective GW1000.
By the way - Weather Display in its latest logger version doesn't show the lightning data either even though it reads them from the GW1000.

It looks as if this special situation: GW1000 + the WH57 extra sensor (lightning) only (and no other outdoor sensor) is not (yet) covered by the logger.
The GW1000 with the WH57 only is used in a multi-station setup, where the GW1000 is supposed to provide the lightning data.

@Boris:
if you want/need a GW1000 + WH57 only test environment, let me know.

I have sent an email with related information to Boris and Brian (Hamilton, WeatherDisplay) to let them know that there is a constellation not covered by their logger code.

[Gyvate]

The Weather Display logger has been corrected and shows the lightning sensor and its strikes now, even when the WH57 is the only external sensor of a GW1000/WH2650. (that's, I guess, of interest only for those who [also] use Weather Display together/in parallel to Meteobridge.

Looking forward to getting/seeing this corrected in the Meteobridge logger soon.

[kd7eir]

718 lightning strikes in the last 90 minutes and MB Pi is reporting 0 to Meteotemplate. Mapping is correct in MB. I really do not understand why MB thinks that lightning is nothing important and refuses to fix this. FFS, the iz0qwm / ecowitt_http_gateway that is TWO YEARS OLD can report lightning!

I 1000% regret ever giving MB one penny of my money.

[weatherist34]

please look at your screenshot it is reporting lightning , perhaps your issue is meteotemplate not having the correct api string .
to find out what that should be is simply done by clicking on the number of lightning total and a tooltip,will appear with a string . once you have established what the string is then simply send that too meteotemplate dev and they can add that on to,the existing api output . this is how we established to use a weatherflow lightning method ,boris did his bit it was upto us to work out how to use that data . note also if possible make the lightning sensor a primary sensor ,not actually owning one ive no idea of what would appear . fwiw i have been liasing with a ecowitt user for a week or so but unfortunately im away for another 10 days without access to anything meteobridge. im sorry but Boris has done his part and your meteobridge device is reading the data from the lightning sensor as per your screenshot then it is now upto the template devs todo their part.

for weather34 users
note ecowitt seems to introduce hidden problems when firmware updates occur for that gw1000 or alike thing , you will miss the first strike recorded after each gw10000 firmware update .so there is a new optional module forthcoming once it has been tested thoroughly ,i wont release it until it is verified this is the common way for the use of that particular device and sensor.no point in releasing it if there is no common setup method for this device as i dont wish to get sucked into multiple configuration scenarios .

@graham wolfg once you have established a connection to meteobridge with your lightning sensor drop me an email sometime after 10th July i will compile an optional module just like i did for chuck see https://myrtleweather.com/console/index.php to use lightning ,
simply we can name it weather34-lightning-ringwood then you can record chart data with daily monthly yearly as you do with air quality.

*note 10th July onwards until then not possible .

kd7eir chill out have a beer , go hammer your morse key and send some morse 73s OM G7LIJ/TA not qrv for many years…brian

[woolfg]

Hi Brian

Thanks I will do that

At the moment Meteobridge is not recognising my lightning sensors at all. They dont appear in any sensor or mapping list

I bought the GW1000 and WH57 purely for the lighnting sensor as an alternative to spending hundreds of pounds on a Boltek. I have no plans (or interest) in adding their weatherstation as I am more than happy with my Davis Vantage

Rainer has been very kindly helping me to sort out the problem but it appears it needs some more work on the Meteobridge side

Regards

Graham

[Gyvate]

@kd7eir:
I think you're off topic here (as @weatherist34 mentioned) - your lightnings are shown in MB and "only" not in Meteotemplate.
You can get a working API string from me - but then it won't work via the Weather Networks, only with a https request.
MB has to improve their string - what didn't happen so far. Workaround: use your own (corrected) http request.
But, be aware that the Meteotemplate database schema only offers one value "L" for lightning - what you send (strikes or distance) is up to you - or you re-purpose another field for accommodating the distance.

@weatherist34:
Brian, I think you are barking up the wrong tree here - the fault is not with Ecowitt here. It's that the constellation GW1000 console with only a lightning sensor is not yet covered by the MB logger code. An unusual constellation obviously not considered in the programming. Weather Display also had to correct their logger code - and did it.
And, once the lightning sensor is shown in MB and the data is available in the MB database, it also appears in the Aurora MKII template (provided you use the proper API string). It works well in my case.
The issue here is a console with indoor sensors plus one non standard outdoor sensor not being covered by the coding - what the WD example proved.Brian Hamilton found out very fast what needed to be corrected after getting the data (2 trials and beta testing by me) what needed to be done.

And, regarding the strike count issue (one less), it's again not related to the firmware.
Otherwise my weewx installation would show the same effect - but it doesn't. Weewx uses the same GW1000 API and the driver isn't updated by the programmers with every firmware update (and the driver I use hasn't been changed over the last 4 GW1000 firmware updates).
So the console reports the strikes properly.
If weewx also reported one strike less, I'd agree with you.
Also, the WSView app reports the proper count - another piece of software which processes the data the GW1000 sends on its request.
That all speaks for MB being the culprit here.

Your template (by the way a very nice one) sits at the end of the chain - and here your supplier is Meteobridge - and for whatever reason MB reports in daily lightning events one strike less, somehow loses one, which other software using the same API, i.e. requesting the GW1000 to send its sensor readings, do not do.

Of course, if this is not mended in MB, providing an extra strike in the daily counting by your template, would compensate for the issue.
Maybe with an option to be set (in case later on it gets corrected in MB) like "compensate GW1000 missing lightning count" which one can tag/untag.

By the way, there is another thread here waiting for resolution regarding the lightning counts:
viewtopic.php?f=61&t=15773

The (earlier wrong) assignment of lightning distance and strike count to the MB database fields has been corrected by Boris meanwhile.

[weatherist34]

@kd7eir:
I think you're off topic here (as @weatherist34 mentioned) - your lightnings are shown in MB and "only" not in Meteotemplate.
You can get a working API string from me - but then it won't work via the Weather Networks, only with a https request.
MB has to improve their string - what didn't happen so far. Workaround: use your own (corrected) http request.
But, be aware that the Meteotemplate database schema only offers one value "L" for lightning - what you send (strikes or distance) is up to you - or you re-purpose another field for accommodating the distance.

@weatherist34:
Brian, I think you are barking up the wrong tree here - the fault is not with Ecowitt here. It's that the constellation GW1000 console with only a lightning sensor is not yet covered by the MB logger code. An unusual constellation obviously not considered in the programming. Weather Display also had to correct their logger code - and did it.
And, once the lightning sensor is shown in MB and the data is available in the MB database, it also appears in the Aurora MKII template (provided you use the proper API string). It works well in my case.
The issue here is a console with indoor sensors plus one non standard outdoor sensor not being covered by the coding - what the WD example proved.Brian Hamilton found out very fast what needed to be corrected after getting the data (2 trials and beta testing by me) what needed to be done.

And, regarding the strike count issue (one less), it's again not related to the firmware.
Otherwise my weewx installation would show the same effect - but it doesn't. Weewx uses the same GW1000 API and the driver isn't updated by the programmers with every firmware update (and the driver I use hasn't been changed over the last 4 GW1000 firmware updates).
So the console reports the strikes properly.
If weewx also reported one strike less, I'd agree with you.
Also, the WSView app reports the proper count - another piece of software which processes the data the GW1000 sends on its request.
That all speaks for MB being the culprit here.

Your template (by the way a very nice one) sits at the end of the chain - and here your supplier is Meteobridge - and for whatever reason MB reports in daily lightning events one strike less, somehow loses one, which other software using the same API, i.e. requesting the GW1000 to send its sensor readings, do not do.

Of course, if this is not mended in MB, providing an extra strike in the daily counting by your template, would compensate for the issue.
Maybe with an option to be set (in case later on it gets corrected in MB) like "compensate GW1000 missing lightning count" which one can tag/untag.

By the way, there is another thread here waiting for resolution regarding the lightning counts:
viewtopic.php?f=61&t=15773

The (earlier wrong) assignment of lightning distance and strike count to the MB database fields has been corrected by Boris meanwhile.

yawn
im not barking up any tree and not making any claims i dont own any of this hardware just happen to liaise with phil before I went away for 3 weeks and we had it working as expected with him creating false strikes ,so i dont see it has a boris problem what is needed is to,set the lightning sensor as a primary sensor and i simply provide a small module compiled,for that brand .

to be honest what is needed by template devs is a common tested reliable method in regards to ecowitt and alike .when i look around the forum i see no solid concrete method , just alot of confusing information that only prolongs the reliable support for this brand.as far im concerned i can live without supporting the brand because it doesn’t conform to anything commonly used ,some of you have already tried to hold me accountable for lack of support for this brand but from my side of the desk i see nothing that changes my thought about supporting this brand in the download.as you clearly say grahams hardware device is not compatible so there comes another confusing array and more hesitation from me to release a general master download with ecowitt support.

moral of what im saying is establish a common method so all template devs can develop around it so everyone is on the same boat , how devs display the output is entirely down to their design skills.

[woolfg]

Hi all

I really dont understand why my setup is causing so many many issues - it doesnt seem to be that complicated

I have

1 Davis Vantage Pro
Two Air Quality sensors
1 Lightning sensor

It seems to me to be quite straightforward

Regards

Graham

[Gyvate]

I think the issue is quite clear and has been communicated to the developer (Boris).
The ball is now in his court.
Everything else looks like secondary "war places" to me.

[kd7eir]

I am quite aware that the data is in MB, as my post said MB is not "sending the data to Meteotemplate". Meteotemplate is NOT the issue as shown in the attached screenshot. That lightning data is being reported to Meteotemplate by the FREE FOSHKplugin using the Ecowitt API.

You would think that a PAID product could perform AT LEAST as good as a FREE product, but that is not the case with Meteobridge. The ONLY issue is that Boris REFUSES to fix Meteobridge and keeps offering lame excuses instead of doing anything about it.

I like the concept of Meteobridge, it was a pioneer in it's day, but now it's nothing but a crippled piece of PAID software. When your PAID software is being eclipsed by FREE software, it's time to either step up your game or move on.

Ecowitt has a massive worldwide following that is growing by the day, and with software like the FOSHKplugin adding new features on a very regular basis and being FREE, Meteobridge is starting to look very long in the tooth.

If I didn't care about Meteobridge I would not be here trying to get Boris to fix it. He deserves the money he charges, but ONLY if he stays on top of things and embraces new systems.

[Gyvate]

I think Boris got the message and is aware that something needs to be done for the remaining lightning issues to be solved.

As for Meteotemplate, I think two things need to be fixed - one with Jachym at the Meteotemplate (MT) end to adapt the database schema to today's needs as far as Ecowitt sensors are concerned. Then the "normal" API string for MT can be fixed.

FOSHKplugin doesn't - afaik - use the official MT API, but an interface (plugin) created by one of our Italian friends. That also works display only but is not an official interface supported by MB. Hence I think it's not fair to compare. This unofficial MT plugin circumvents the API string and provides data for which there is no place (yet) in the database schema for temporary display without archiving.
If this is not so, I'd stand corrected.

That's why I created my own http string, which is accepted by the MT API as long as data is sent for which fields exist in the database schema.
You can also send data to a plugin, but you have to define this yourself - and you can do this with MB and/or with the FOSHKplugin.

Still the official MT API support should be corrected. But it won't solve the problem that the MT Ecowitt plugin from Raffaello only displays values which are not in the database schema but doesn't store them. That part Jachym as the owner of Meteotemplate has to provide.

So we shouldn't compare apples with pears. Boris/MB only claims to deliver to the MT API, not to the Ecowitt plugin.

You can blame Boris for an incorrect or incomplete API string in the weather networks, but not for the missing corresponding database fields.
His string should contain the L= parameter, and someone will have to tell him which sensor to send with the L= parameter:
lightning_total, lightning_energy, lightning_distance - and he will take what the owner of the API (JAchym) says. And as far as I know Jachym hasn't said anything here yet.

If there were (resp. as soon as there are) database fields for the lightning distance (which are not there now at MT), they/it should also be provided by the MB string sent to the MT API.

[kd7eir]

FOSHKplugin never actually used the Ecowitt HTTP gateway plugin. I posted about how I could feed the plugin with FOSHK, but it now uses the API and I've deleted the plugin.

[weatherist34]

important to understand boris will only add or change the API for a specific network or template based on request from the dev ,he wont change based on his own assumption because thats how things break if there is no communication between himself and the dev.

kd7eir i can tell from your previous screenshot of mb history that its no brainer to have your lightning data displayed on your website ,i reiterate the template dev needs todo his part and communicate this to boris.

im sure sooner or later this will be all working just hope its a universal solution not a specific user case.