this is all clear and long stated in the WiKi - the 79 interval gets
restarted once a discharge is detected.
But thinking that a SDR would receive values more often and faster than
a normal Ecowitt console (that was the statement I was referring to) is
an illusion.
That's at least how the statement reads to me - maybe it was not
properly formulated.
saying " If there is a possibility to extract a singled detected
lightning event and
> it's data with standard devices, is another story. If so, I'd see the
point
> of doing so. At least the minimal distance and weighted average distance
> are interesting values to me."
and
"I doubt it is possible doing this with the
> "Ecowitt Gateway Driver", I have no idea if it is possible with the
> interceptor driver and a WH2551, it should be possible using SDR."
means that a SDR can do what an Ecowitt console or Gary's driver can't do.
The text says it's doubted that the standard devices can detect this
(assuming "standard devices" are Ecowitt consoles with the local Ecowitt
API), and this doubt is not justified by anything. Of course they can.
And why Gary's driver should not be able to retrieve these readings is
also a mystery to me. Of course it can, probably down to one second.
But the retrieval is from the console, not from the sensor, and the
console produces added value to the sensor transmissions.
That a SDR should be superior here is by no means true - but of course a
SDR can be used.
But it won't get anything faster and more than the Ecowitt console.
and then
"I think the main difference is that the Ecowitt consoles can only be
polled, or configured to push data a defined interval. As far as I know,
there is no such event mechanism from the console to other devices,
messages queues, whatever. But I'd be very happy, if someone would prove
me wrong."
What else should the console be able to do but receiving sensor data,
(pre-)processing them and responding to an API request or posting data ?
Nothing more is possible and makes sense as the data provider only sends
data - there is no bi-directional communication.
At least not in the usual unidirectional sensor world.
The console already provides additional data which the rtl_433 software
probably doesn't provide. rtl_433 only decodes the sensor post (afaik).
And the sensor is dumb. It posts only the event distance which its chip
has calculated and assigned to the 14 possible values.
Summary count and time-stamp are added by the console.
"Your information does not fit the observed reality."
I guess you didn't read the WiKi properly. And in my mails I didn't say
that the interval isn't interrupted and as a result the discharge is
immediately transmitted. On the contrary.
You probably misread or misunderstood my text.
I was only referring to the insinuation that a SDR should be able to do
something what the console (and via the console) Gary's driver cannot do.
All data is available - but the processing in the way you may like it is
not. This needs to be programmed and the data stored following a
suitable data model.
"As far as I know, there is no such event mechanism from the console to
other devices, messages queues, whatever."
There is - in the context of Ecowitt IoT devices.
There you can trigger IoT devices based on sensor readings, single or
combined.
This general process could be used ...
And, there may be something more in the bush - originally meant for the
communication with IoT devices.
As I don't know the full API description yet, it's too early to make
reliable statements.
I think what would be helpful (at least for me to understand better -
maybe I simply don't get the point ... - maybe it was already all
clearly presented but that portion got cut off from the thread) to have
a draft architecture of what exactly you want to do - not only
verbalized but also drawn in a picture.
And then describe for which steps/areas/segments you think you already
have tools/solutions and for what not.
1. to see the gaps
2. maybe to revise the whole architecture in a target oriented manner
and then see what's already available and what needs to be added
Having been working as an IT and network architect, I'm not so much into
a Lego block approach but in a more structured approach.
Big picture first - and then drill down in a result- and technology-open
mindset
A picture is worth 1000 words they say - and in my experience this is
very true
On 03.06.2024 17:56, 'michael.k...@gmx.at' via weewx-user wrote:
Rainer, the WH57 sends lightning data as the lighning is detected, the
console shows this data immediately.
I observed this mutliple times:
You see the lightning out there, the LED of the WH57 flashes red, the
counter on the console goes up, the distance is also updated. If there
is a lightning just a few seconds later, the same game again. Even
when polling the console API in an interval < 79s, you get the
lightning data updates more frequently than 79s.
Your information does not fit the observed reality. Whats true is that
you need to store lightning data in a different format, to calculate a
meaningful value for the archive record. Something like the count per
interval and a kind of weighted average for the distance. It exists
for the Tempest, which transmits lightning data using UDP as it
detects a lightning. Apart from the other data which is transmitted in
a constant interval.
Rainer Lang schrieb am Montag, 3. Juni 2024 um 17:25:34 UTC+2:
"If there is a possibility to extract a singled detected lightning
event and
> it's data with standard devices, is another story. If so, I'd
see the point
> of doing so. At least the minimal distance and weighted average
distance
> are interesting values to me. I doubt it is possible doing this
with the
> "Ecowitt Gateway Driver", I have no idea if it is possible with the
> interceptor driver and a WH2551, it should be possible using SDR."
what part of transmitting every 79 seconds has not been understood ?
And the 79 seconds start with the first detected discharge.
Why would SDR receive more and more often ? Magic SDR ?
SDR is nothing else but a radio receiver as is a console.
Just by changing the console the sensor won't post faster.
And it's not an Acurite chipset (maybe some Acurite device uses
the same chip);
it's an AS3935 - before starting wild speculations I would read
the specifications and see if the chip can be animated to provide
data more frequently.
Then you can try your luck modifying the sensor firmware if that's
possible and not limited by the chip itself ...
And have a look what exactly the chip provides/can provide ...
check if it provides such things like minimal distance, weighted
distance etc.
Nice wishlist, but as far as I have understood the specifications,
it doesn't do that.
Admittedly, I'm not an expert here - somebody else may be able to
extract more information
Google can be your friend - look up the AS3935 specifications/data
sheet etc.
But as for the WH57 as manufactured, it will transmit every 79
seconds ....
And it has nothing to do with the Ecowitt Gateway driver or any
other driver - you can have it poll every two seconds.
But it can get only what the console has available to send. And
the console only has what it receives from what was transmitted.
Maybe it would be helpful to understand how weewx works ...
Classically the data received from a driver or extension is
collected in a loop where data gets accumulated.
That doesn't seem to be what you want. You seem to want every
single data-item to be recorded separately.
Then you will also have to write the code which does this and save
the data in a way you can reuse it - i.e. write your own extension.
You'd probably need your own separate lightning database for that too.
In the typical way weewx works, collects and archives data that
won't work as far as I can see.
By the way - if there are no more discharges within 79 seconds,
your request above will be fulfilled 😉
all the sensor related information could have been found and read
in the Ecowitt WiKi
https://meshka.eu/Ecowitt/dokuwiki
On 02.06.2024 19:25, 'michael.k...@gmx.at' via weewx-user wrote:
Probably the only way getting reasonable data is with SDR.
michael.k...@gmx.at schrieb am Freitag, 25. August 2023 um
07:32:51 UTC+2:
My best guess is that the Sensor reports every 79s "Hello,
I'm there" and every detected lightning on top of that,
immediately. If you don't live at Catatumbo River mouth, this
shouldn't drain the battery too much. Let's see if Rainer
Lang knows more Details.
Greg Troxel schrieb am Freitag, 25. August 2023 um 01:53:48
UTC+2:
"michael.k...@gmx.at" <michael.k...@gmx.at> writes:
> I am just now in the middle of this Storm with
stroboscopic-like lightning
> flashing.
>
> I recognized my HP2551 is obviously showing lightning
strikes in realtime.
> Every one or the other second.
>
> Then I checked back in the manual and now disagree with
gjr80, when he
> states:
>
> gjr80 schrieb am Mittwoch, 21. Juni 2023 um 22:32:42
UTC+2:
>
> In essence the WH57 reports three things; the number of
lightning strike
> detected today, the time of the last detected lightning
strike and the
> distance of the last lightning strike. This is clearly
stated in the WH57
> manual.
> Gary
This sounds very much like the chip that is in the
Acurite 6045M
> If there is a possibility to extract a singled detected
lightning event and
> it's data with standard devices, is another story. If
so, I'd see the point
> of doing so. At least the minimal distance and weighted
average distance
> are interesting values to me. I doubt it is possible
doing this with the
> "Ecowitt Gateway Driver", I have no idea if it is
possible with the
> interceptor driver and a WH2551, it should be possible
using SDR.
Certainly it would be great to log the bits and study
them. The 6045M
only transmits periodically, with a longer period without
lightning and
then faster in 'active mode'. I suspect the chip reports
immediately,
and there is a different radio in the WH57. There is no
reason why it
couldn't be set up to send promptly, other than battery
life.
--
You received this message because you are subscribed to the
Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/437ddc4e-27e4-409c-952d-4555f8a855d7n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/437ddc4e-27e4-409c-952d-4555f8a855d7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/59dc1609-6909-471e-9e83-9b7036a58249n%40googlegroups.com
<https://groups.google.com/d/msgid/weewx-user/59dc1609-6909-471e-9e83-9b7036a58249n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/0aab039e-c5ce-4101-9d2a-daa22f607249%40gmail.com.
