Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]
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 bette
Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]
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 w
Re: [weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]
For others lost in the arguing :-) the wiki page is at https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#wh57 and the discussion about their APIs is at https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#apis_application_programming_interfaces It was interesting to see some discussion in that wiki suggesting the console displaying in realtime (or not) depends on which console you have - https://meshka.eu/Ecowitt/dokuwiki/doku.php?id=start#ws3800_and_ws3900_ws3910 as one example. -- 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/1370988f-6131-42b5-b89d-37ae23ae8573n%40googlegroups.com.
[weewx-user] Ecowitt Gateway Driver, WH57 and lightning data [4]
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 frequen
