Today I recorded this: https://www.youtube.com/watch?v=SaAj23eqhh4 I have no other explanation than the WH57 reports lightning strikes more often than every 79s.
michael.k...@gmx.at schrieb am Dienstag, 4. Juni 2024 um 21:15:41 UTC+2: > Let's boil it down to this sentence: > > > That a SDR should be superior here is by no means true - but of course > a SDR can be used. > > If the sensor emits every single lightning event, and the console can only > be polled, or set up to send data in a fixed interval: it is by all means > true! > > It is polling vs. event based data. It would be ridiculous, to try to get > every lightning event, with polling the device every second. Even if you > did so, there would be occasions, where multiple lightnings could be > detected within the second. SDR would receive the events as they happen. > For such event driven data, sampling with fixed intervals is just not the > right solution. And that is what the weatherflow guys do much better, than > the ecowitt people. > > Rainer Lang schrieb am Dienstag, 4. Juni 2024 um 20:00:40 UTC+2: > >> 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+...@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/0b60fed8-b72f-4e71-a423-8fcde2eeae32n%40googlegroups.com.
