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

[jmontamat]

I see that the problem is in RPI hardware and meteobridge Pro, in TP-link and D-link works fine.

[Gyvate]

It's highly unlikely that it is a hardware issue. It's an issue related to the hardware MB runs on - in the sense that the MB software works differently i.e. has different implementations on different hardware. But it's not that the hardware "eats" the strike counts.
Then the same or similar thing would occur with weewx what it does not if it really were a hardware issue.

Let's put it this way, the implementation of Meteobridge on a MB Pro device or on a RPi shows the issue.
So the issue is not in the hardware but in the implementation on the hardware.
Maybe that's what you wanted to say.

But it's a good hint and probably useful for Boris that it (seems to) work(s) properly in the router implementations.

[jmontamat]

GW1000 as primary station and only, with WH40 WS80 WH57

[wvdkuil]

GW1000 as primary station and only, with WH40 WS80 WH57

As discussed above:
The problem occurs when there are no other "main weather-station sensors" in the device setup
A GW1000 has inside (console)-sensors. But this user has no "real" outside sensors for outside temp-humidity.

I myself had to adept my Ecowitt receiving scripts, Brian Hamilton (WeatherDisplay) had to adept his scripts also.

Your situation is totally different:
You have a standerd configuration, a complete weather-station with outside temp-humidity, rain a.s.o.
And yes that functions correctly as hundreds of users are using that configuration, so the problems are ironed out for those.
And yes, a "normal" station can be enhanced with almost any sensor, probably all of them in any combination are already tested.

Probably more and more users start using a GW1000 to add missing sensors to their main station.
When the multi-station feature was first tested, we added a GW1000 also.
We added multiple and different extra sensors, all combinations worked and the feature was released.
But it were complete stations, with outside temp-hum.
Or complete stand-alone extra sensors, such as PurpleAir, Luftdaten, DavisAQ.
It did not cross my mind to add a GW1000 with only an AQ sensor. Or only a lightning sensor.

Sadly, the OP uses an unique configuration, which was not tested in the past.

Wim

[woolfg]

Hi

As the original poster I would just like to say that I DO have an outside weather station - its just not an Ecowitt

My Primary station is a Davis Vantage Pro

I just want the lighting data from Ecowitt

Regards

Graham

[kd7eir]

Meteotemplate dev does NOT need to tell Boris anything, Boris only needs to use the CORRECT FIELD NAMES AS DOCUMENTED in the ECOWITT API.

The API is from ECOWITT, it's documented. Boris has been ARGUING because HE cannot comprehend the CLEARLY WRITTEN documentation of the Ecowitt API. Even when presented with FACTS that show HE is the problem, he brushes it off with his trite "That's a niche issue" BS. He's been pointed to other implementations that show that HE is the problem, he brushes that off with the excuse that he "can't decipher the CHINESE (he harped on that) documentation". When given an example so clear that a 7 year old could comprehend it, he ignores it.

Nobody is asking Boris to add the fields to the database in Meteotemplate, that's trivial enough for a high school student to do. He's simply being asked to use THE DOCUMENTED FILED NAMES. FFS, he could fix that in less time than it took me to write this reply.

[Gyvate]

I think to some extent the Meteotemplate issue is out of context of the OP.
The thread subject clearly says what it is about.

But I also think the Meteotemplate "issues" described by you are none of Boris' responsibilities.

The Weather Network part of Meteobridge posts to different weather networks, and Meteotemplate is considered one of them.
Like WU, PWS, WindGuru etc. the network owners define the interface (API) which receives data.
And for Meteotemplate this owner is Jachym - he has created and defined the Meteotemplate API (see MT Wiki).
Meteobridge sends data to this API as per Jachym's API definition. This should be correctly programmed as it is offered as a feature - and if it is faulty the bug needs to be fixed.

This MT API knows only one lightning value "L", and it's even not defined what exactly it stands for: count, distance, time_stamp.
So MB can even not provide all data for the official MT API. And will do so only when there is an official statement/request from Jachym how to handle which field - and until now Jachym refers only to fields which are defined in his database schema. So MB is not to be blamed here.

And, as @weatherist34 also mentioned, a software developer will liaise will the API owner.
Meteobridge offers the possibility to go beyond the standard features by using e.g. user defined http requests.

What people e.g. Raffaello from Italy have done is something else - they have created a plugin (or meanwhile more than one) in which one can receive the data from an Ecowitt console in Ecowitt protocol. They did that because they like the MT concept and wanted to enhance it with features by plugins.
This has nothing to do with Meteobridge - even though you could write in/for MB a http request which sends data in Ecowitt protocol to the plugin. But that's a "private" activity a user can do - it's not per se a MB feature to send data in Ecowitt protocol.
And this data sent via Ecowitt protocol cannot be stored in the MT database, only used for temporary display (which may be fine and enough for many users).

Documentation issues which Boris had were related to the lightning sensor values in the GW1000 API - this is meanwhile sorted and works.
That's no longer an issue. The missing 1 count issue (somehow MB records in the database one count less than the real occurrences) still needs to be attended.

As I mentioned earlier - the users of Meteotemplate could approach Jachym for a new database schema (what he has been talking about already for some time) and make sure that the sensor values provided by all the recent Ecowitt sensors find a place in that schema. Inspire him to launch a new database schema campaign where users can present their needs.
Then Jachym can rework his API and then programs like Meteobridge can send all the data which is needed to that official (new, extended) interface.

[Bart]

Hi

As the original poster I would just like to say that I DO have an outside weather station - its just not an Ecowitt

My Primary station is a Davis Vantage Pro

I just want the lighting data from Ecowitt

Regards

Graham

I read this and then followed it with increasing interest as many super experts (I'm still learning) seemed to be/get involved.
I thought it would solve @woolfg (Graham) problem and then also my configuration problem. But apparently there isn't

I have a Davis Vantage Pro (plus), a Davis AQ, MB Nano SD, an MB RPI and a WLL. ........
And also an Ecowitt GW1000 on which the information from a WH51 soil moisture sensor comes in. I bought it (bargain) as a set at a garden center. The soil sensor was a by-catch, as it were, because I first wanted to test whether it could communicate with my working constellation. In fact I want to buy the same lightning detector WH57. I couldn't find it yet. At least not in Europe…but that could be just me.

So basically I thought Graham experiencing the same as I do and could be solved.

I notice that my GW1000 does transmit 4 values ​​(indoor, hum, air pressure 2x) in the MB (I used the RPI) but not (in my case) the percentage of moisture of the soil, the only info from the WH51.. Those values ​​that are passed on are of course already known to MB, they are reported by the primary station.

Actually I see the same as what Graham observes, only my problem is a bit simpler, I don't have to make a 'trial lightning' every time. Although I can do that.

A wordaround on a workaround does not seem the right way to me. Then it will turn out that a problem arises elsewhere.

I thought to add this to make it clear that it doesn't seem to be just the lightning detector (WH57) that reports something wrong or not at all. Or is there a soil moisture solution and is it possible?

Bart

[Gyvate]

In Europe you can get the WH57 as a Froggit DP60, provided your GW1000 receives at 868 MHz.
If your GW1000 receives a WH51 as only outdoor sensor (outdoor in the sense not indoor temp/hum/pressure), then probably MB won't receive it either.
The logger is not (yet) completely programmed "through" for all constellations as most users have other basic outdoor sensors like outdoor temp/hum, rain, wind with a GW1000. So far the only weather software which have corrected this are weewx and Weather Display, and WeatherDisplay only as a reaction to this post. They can now handle a GW1000 with a WH57 or WH51 only. Meteobridge is still lagging behind.

I made a test with the following constellations:
1. GW1000 + WH57 : only indoor values shown
2. GW1000 + WH57 + WH32: indoor and outdoor temp/hum shown - WH57 not
3. GW1000 + WH57 + WH40 (rain gauge) + WH32: indoor and outdoor temp/hum and rain shown - WH57 not
4. GW1000 + WH57 + wind (WS80) (=outdoor temp/hum + wind): all sensors shown, also WH57
5. GW1000 + WH57 + WH31: indoor and extra temp/hum shown, WH57 not
AND
6. GW1000 + WH51: indoor values + WH51 (soilMoisture) shown !!! (unexpected, but who knows how the logger was programmed)

EDIT: the result of #6 may have been due some buffer data still available - in the next post a user reports that for him this constellation doesn't work either.

Result: in order for MB to pick up and process the WH57 signal with a GW1000 in its current programming, an outdoor temp/hum and a wind sensor need to exist/be active

It's very clear that the MB logger needs some update/modification to pick up the WH57 sensor when it's the only external sensor,
and also for the case that a WH32 and/or one (or more) WH31 are present - in those constellations MB fails to detect/process the WH57 sensor.

[Bart]

......AND
6. GW1000 + WH51: indoor values + WH51 (soilMoisture) shown !!! (unexpected, but who knows how the logger was programmed)

On my RPI it is not showing the soilMoisture. Or did I misunderstand the meaning of "logger" in your explanation? Or is it possible that there is a deviation between your logger (an MB Pro?) and MB RPI?

[Gyvate]

My tests were done on a MB Pro - don't want to mess with my RPi production installation.
And don't have a spare RPi to set up MB there for testing.
And, I don't know if the logger code used for the MB Pro and for RPi is different.
The assumption is that it's not, but who knows - noone but Boris.

But it's possible that the WH51 showing in my tests when being the only outdoor sensor is some dirt/cache effect in the MB Pro (which could have been the same in the RPi).
I didn't completely reset and re-install the MB Pro between tests - only removed or activated a station (and replaced it with a different one between test scenarios) - but this might not have been enough. So there is a possibility that both our finding are "correct"
(and at the end of the day the single SM sensor + GW1000 doesn't really show).

[Bart]

Ok, tomorrow I will try de same as I did before on a MB Nano SD. I wonder if there will be a difference.
Bart

[jmontamat]

I wanted to buy a license for RPI pro in view of the success I am going to wait ...

[Gyvate]

I wanted to buy a license for RPI pro in view of the success I am going to wait ...

RPi pro = ? I guess you meant a RPi (vs. a MB Pro)
Unless you have a WH57 lightning sensor as your only outdoor sensor with a GW1000, you're not affected by this bug and you can get your license.
As soon as you have an outdoor temp/hum and wind sensor with a GW1000 (e.g. a 7-in-1 WH65 array or a 6-in-1 WS80 array*), all other sensors are properly picked up by Meteobridge, and the bug will hopefully be eliminated soon.
In my templates the lightning strikes show - where implemented (see signature link)
And MB on a RPi4 is very performant. The 2 GB version is more than sufficient.

*) for details on sensors etc. see https://www.wxforum.net/index.php?topic=40730.0

[Bart]

Ok, tomorrow I will try de same as I did before on a MB Nano SD. I wonder if there will be a difference.
Bart

Sorry, I haven’t had the opportunity yet Gyvate.