Mapantz wrote: ↑Sat 06 Jun 2020 6:03 pm
You'd need some fancy code to workaround that, unfortunately, that's well above my pay grade.
I suspect it is as simple as adding some code to store values and a conditional to compare new values against stored values. It is a simple, but frequently used technique. Cumulus code is full of it, that is how the extreme records are updated and the alarms are triggered.
Your difficulty sounds very like the discussion in another topic about Cumulus not giving the correct latest wind gust updates. Mathematically, what was wanted was a rolling gust value, still calculated over 10 minutes, but actually being updated as the individual minutes progressed, instead of waiting until the previous 10 minutes had ended. The problem in that case was that the gust value reported by Cumulus stays the same for ten minutes, before the next update of it, even if the wind has died down or the wind speed has increased above the gust still being reported.The solution selected in that case was to compare the current gust value coming in with the previous gust value. If the current gust value is the same, discard the current gust value and use the latest wind speed instead if that is higher, until next time the gust value changes when you use that. You can look up
viewtopic.php?f=11&t=17844 topic to read more.
In your case, presumably
you could write some code to set both lightning time and distance back to null if the record you are reading in for next graph plotting point has not produced different values to the previous read for lightning time/distance. Use of a null should create a gap in your graph avoiding that flat lining.
If you prefer to use zero rather than null then the graph should go down steeply, try that too to see whichever works best for you in your graph.
In a very very much earlier topic, somewhere on this forum, somebody was asking Steve Loft to change the standard (monthly) log to record maximum and minimum since last the last line on the log, so you did not miss any extremes that Cumulus read in-between it writing to the log. I still think that was a good idea, and it is a pity it was never implemented. It would reduce the number of uploads by still getting same information to a web site as is currently available in real-time, for the cost of sometimes having to wait longer for an update.
With reference to my recent project on data log editor, the software that Mark uses provides an event when a value in a field changes. I use that event, but there were two clever tricks needed to make it work. These might well be "above your grade"! It was new to me, but certainly possible. I wanted to monitor changes in three fields, so I had to use an anonymous function for the event in all 3 fields. Trick one was to have empty functions in the first two fields, they needed the function to be declared for that field to be monitored; but all my handling code had to be in the last declaration, as that in effect overwrote any event handling in the same anonymous function included in previous two declarations. Trick 2 was to ignore the first 3 calls to the function, they related to when the original values were added to the screen, I was only interested when the Cumulus user actually edited one of the three fields, so my action is only triggered on 4th, and subsequent, calls detecting which item was edited to decide what parts of my enhancement had to be modified from what I had originally output.
That boasting won't make much sense unless you sign up to be a tester and see what my enhancement is!
