Cumulus Support

Hans.
Now I believe I have sorted the Airlink/Nowcast code I come back to the lightning ( especially after logging a few strikes yesterday! )

If you log it to a CSV file in a continuous timeseries you already can chart it in CUtils (after some additional work on my side).

I had a look at the wi-ki but cannot for the life of me work out what to do with a CSV file of strike information so I can
display it in CMXutils. (must be the clammy weather fogging my brain.) Can you point to an example of taking ones own data for any subject and producing a chart.

I have the data in an sql database at the moment but can obviously create what CSV is required.

Thanks as usual for any pointers.... MIke

Ah, I said that here and I hinted at the possibility of CUtils to plot any time/value series as an external extra sensor. My additional work to be done is to make a chart for more that one value per line. So a csv line would be:

<date/time>, value1, value2, value3, ... valuen

and all values would be plotted in the chart.

That work has not been done yet.
I understand you would like that to be available

The temperatures will be going down soon and than up again towards the end of august, I'll look at it but not sure when that will be finished.

In the mean time you could do the same by making the lightning PlotVars you need as a timeseries in their own csv. I think that would be LightningStrike and LightningDistance. I assume you would like to do some calculations yourself beforehand to get the nr of strikes per minute or so and work the 255 turnover. If you make a csv for each of these PlotVars you can plot them against the time (its always a timeseries). Cutils would automatically plot them in one chart.

Hans,
Part of the problem I have is deciding precisely what to plot. Having used blitzortung and the WH57 I think the distances it comes up with are not worthy of saving (which I believe other folk have noted). I appreciate it isnt the actual strike that is that distance away but the storm front as per the documenation. (for example the last strike data : Blitzortung says 33miles and wh57 says 17 miles!!)

Maybe I'll think about plotting num of strikes per hour or per day and plot that.

So that would be a csv with date-time, number-in-that hour
where date-time increments in hourly units or whatever my segment will be.
(so I guess I need to go and read If anyone has any other suggestions please jump in

Mike,

Sorry, I thought I had entered the relevant wiki links in my previous post:

1. https://cumuluswiki.org/a/Extra_Sensors
2. https://cumuluswiki.org/a/External_Extra_Sensors

This should do it for you.

And yes, if you start making your own charts CDL and the Chartscompiler are more or less obligatory to understand what is going on.

Of course it is up to you how you do it, but I would think (in heavy storms) the nr of strikes /hr at least would be interesting and for distance, if you plot points that might be interesting as wel. Whatever, a bit of experimenting must be quite easy once you understand how to handle the external extra sensors. Afterwards you can modify your charts in manual mode.

As the storms that around are 100s for miles away I have got the sensor inside and managed to get a few spike readings. Ecowitt and CMX recorded them in the dropdown 'extra sensors' and the today.ini also updated but I got no change in realtime.txt output. All I need is the distance per strike as I can add the number and time to add to my own program. In simple terms without sql rtl csv etc can the distance be added to realtime.txt

I just stick to logging the daily total of lightning strikes at rollover.

Trying to log each detection isn't straightforward, and is also beyond my knowledge. It's simply to do with the fact that there's only 3 bits of data available. <#LightningDistance> will always have a value, and it could have the same value for hours/days/months or even years. The same applies for <#LightningTime>

You'd end up with repeated logs of the same data.

As I mentioned, it's beyond my knowledge, but you'd need a way of storing the values as they come in, logging it, then resetting it, until the next genuine value comes in. Otherwise, you'll have continuous graphs showing the same date and same distance.

Obviously, Ecowitt have some kind of code in place to do just that, you only need to view the graph on your Ecowitt dashboard to see it. The little data provided by the current API makes it harder to achieve.

Thanks
If I can get that time and distance data into realtime.txt then only a new time stamp would count as a strike whether the same distance was true or not

watsonm wrote: ↑Wed 20 Jul 2022 2:39 pm

• strike_count : this increments up to 255 before rolling over

I have heard this 255 boundary more often but I do not know where it comes from.
Currently a thunderstorm is passing over my head which gives me the chance to observe this.
I have the Ecowitt lightning detector installed with my CMX4 testsite (see below) and this is what it sshows:

So I assume it will pass the 1024 as well. Interesting.
(good thunderstorm btw. )

HansR wrote: ↑Wed 17 Aug 2022 4:28 pm

watsonm wrote: ↑Wed 20 Jul 2022 2:39 pm

• strike_count : this increments up to 255 before rolling over

I have heard this 255 boundary more often but I do not know where it comes from.

They are referring to the data sent from the sensor over the air, the console/gateway handles the rollover and continues the count, so accessing it from there means no 255 limit.

Aha... that clarifies

Now got the lightning info into realtimegauges.txt and working using spikes so now just need to make a few changes to my own program and wait for the next storm.
Thanks to all who put in their bit, it was just putting it all together (SIMPLE)

b3212/3 realtimegauges.txt now no longer has the lightning data entered. while checking something else I noticed a count for yesterday morning which didn't show with my own software.
When I checked the realtimegauges.txt there is now no data for lightning with build 3212,
updated to 3213 and that was the same. Went back to 3206 and yesterday reading are shown
so staying with 3206

Dave, it might be helpful if you posted your custom realtimegaugesT.txt file so we can see if there is anything wrong with it.

have attached the files as requested. And after having looked at them I think I will phone confused.com as I don't have a clue how the lightning info got into 3206 as The realtimegaugesT.txt in the original zip file is the same as 3213 Mark can I assume that I can go back to 3213 and still use the realtimegaugesT_b3206.txt that works for me

You can, that file has not been updated for a couple of years iirc.

Rather than editing the file provided with CMX though, it may be better to...
1. Make copy of it, add in the extra data you want
2. Switch off the generation of realtimegauges.txt in CMX
3. Add your new file to your Extra Files list, you can set the destination file to the standard filename of realtimegauges.txt

That way your changes will not be overwritten by the standard files each time you update CMX.