I have been bringing in variety of “custom” data points for use on my main ajaxdashboard page. All has gone well, except one. Clientraw[116] is the date of the last lightning strike. For the life of me i cannot get it to convert from d/m/Y to m/d/Y. I have tried the built-in date normalizing functions, i have tried both php and java date manipution functions, i have treated it as a string to slice and dice it and rearrange it. I have tried converting it form a date to a string and then slicing and diceing. Everything reults in no change to the datapoint or crashes with flaming little bits all over my desktop.
I am getting it in ajaxWDwx.js with:
var lltime = clientraw[115];
set_ajax_obs("ajaxlltime", lltime +" ");
var lldate = clientraw[116];
set_ajax_obs("ajaxlldate",lldate);
and printing it in ajaxdashboard with:
<span class="ajax" id="ajaxlightning">
<?php echo $lighningcountmidnight;?></span> today. Last strike at <span class="ajax" id="ajaxlltime"><?php echo $lltime;?></span><span class="ajax" id="ajaxlldate"><?php echo $lldate;?></span>
and as such, it works fine. Lightning count since midnight is not available in clientraw and i get it from testtags.
What am i missing?
Thanks,
Jim
Strange. . . my clientraw 115 and 116 are reversed, according to both Ken’s and Wim’s parsers, and I have a note to say date is always in mm/dd/yy. (My WD is set to dd/mm/yyyy.)
For the avoidance of doubt, my last strike was on 12th August 2024 
Very strange. I am set to m-d-Y.
Jim
Just remembered, there was a bug in the GW2000 that meant it reported m/d/y from the WH57 even when GW2000 was set to d/m/y. So maybe WD just picked up on that.
Bug was fixed in firmware 3.1.5 for the GW2000, and I haven’t had any lightning since. . .
As I remember correctly, the clientraw date-time and unit values originally were metric.
There has been multiple format adaptions in the past.
That is why I added in the parser for some date fields (format depends on wd setting)
I did not find that for the lightning date fields, so I assume it is always d/m/y
My clientraw-parser shows correct values for @jaltman data
| 114 |
number lightning strikes last min |
N |
0 |
| 115 |
lightning last time |
T |
05:26 <> 5:26:33 exceptional data? |
| 116 |
lightning last date |
L |
29/12/2024 |
The code I use: split time on the : and the date on the /
Than use a mktime to get the correct date-time value.
Have fun,
Wim
I have GW1100 and appears to be returning correct data but crongw1000 has the date reversed in WD’s interpreted data. The raw data flashes by so fast i can’t really see it, however on their web interface, its right and formatted correctly to m-d-Y. Curiously, the api returns the current date and time instead of the last lightning strike. I have sent Ecowitt a query about the api, but have not heard back from them yet.
and Thanks Wim, let me look at how you do that. I tried splitting the date on the / but i couldn’t make it work.
Jim
Try something like:
$date = '4/2/2025';
$arr = explode("/",$date);
$sillyUSdate = $arr[1]."/".$arr[0]."/".$arr[2];
Putting that in the code, exactly like that and changing the echo to echo $sillyUSdate, works! Putting in the variable from ajaxWD it blows up. Now, this morning, i had found Wim’s slice and dice routine but then i had to go to work for an hour or two and when i got home, i absolutely could not find it again. So, i went out to my car, jacked up the front end and tightened the hose clamp on the lower radiator hose. Its been weeping. Maybe its a sign.
Thanks for thinking about it.
Jim
1 Like
I have achieved my result. Not exactly in the manner i desired, but close enough. I cannot slice and dice the variable coming in through ajaxWD no matter what i do. But i can do it to the testtags variable with impunity. So i am getting the time of the last strike through clientraw, the number of strikes and parsing the date out of testtags. This means that lightning over the midnight hour might not show the incremented date for up to 5 minutes, but only i will know and i am not up at midnight anyway.
Another thing i have stolen out of testtags is the “am/pm” indication on the time. I don’t really know if the clientraw time is 12 hour time or 24 hour time. If it turns out to be 24 hour time, i will just delete the am/pm and be on my way. There is also a stray space between the end of the time and am/pm indicator, but it looks like its coming from the clientraw time, so i can’t get rid of it.
Just as important, by tightening the hose clamp on my lower radiator hose, coolant no longer weeps out and drips from the bottom of car.
Its being a good day.
Thanks bitsostring and Wim for the help and thoughts.
Jim
1 Like
