My observation count over the last 24 hours seems to be stuck on 1381, but I can’t see any evidence in the charts that I am missing nearly an hours worth of obs. Is something odd going on here?
Interesting…my Sky shows the same number of observations over the past 24 hours.
First, I’m not seeing any bug.
Second, I think it’s an issue where the server lost count do to an issue @eric experienced.
Third, I just looked at the data stored on the servers and I count 1440 records for yesterday and 120 for today. Just as it should be.
Yesterday I was blinded for about 2 hours. My both setups did work all the time
Hub’s red, and no way to link to them via BT locally (via internet and 4G network)
to make the story short, back tracing to the WF servers where we send our data showed 100% packet loss (somewhere on US soil). And stations near me did not have the problem … and is solved as is happened …
So maybe some other had the same problem with some bottle neck for 1 to 2 hours but no way to know who and why as it is doesn’t seem ip range related. Maybe ISP related (in my case Orange) …
Might explain but not sure
Are you talking about your own station, or my station? I have just checked the server for my station, and see a perfect 1440 observations for yesterday, and 492 today (which is a complete set up to 08:12) for both Air and Sky. My observation count for the last 24 hours though is stuck at 1382 for both Air and Sky, which is clearly not correct.
I didn’t see the server issue @eric suffered from yesterday, so I don’t think this is the problem.
@dsj just a note to mention that this issue is persisting for me. Over the last few days I have had between 1439 and 1441 observations per day on both Sky and Air, but the observation count in the app and on the web has doggedly remained at 1382, sometimes decreasing to 1379.
@jim.wn1x, has you observation count stayed the same as well?
The phone application, which I rarely use does indeed show 1381. I will look at the code tomorrow and see if I can find why. That is indeed strange.
It seems to be counting only 23 hours. I wonder if it has to do with daylight saving time or maybe a timezone issue.
Both the iPhone app and the web page are showing 1380 obs count this morning. That said, I’ve see 1381 and other counts on different days.
Gary is correct. Here’s why: The API used to cache 24 hours of observations and that count was driven directly from the cache. We actually only need 3 hours of cached observations but we took a step toward that a while ago and cut it back to 23 hours (as a conservative test). We will likely remove this field from the diagnostic status message the API returns.
Thanks for looking into this .
I’m not sure I quite follow you here. Do you mean you are going to remove the ‘Observation count (last 24 hours)’ field from the web and app under Station -> Status? If so, please don’t! Without zooming right down to the 1-minute graph level and scrolling all the way back through the last 24 hours, there is no other way (I know of) of checking if you have been losing data packets (excluding third party applications of course!).
In fact, it would be great if you could restore the full 24 hour count .
I underestimated. You are caching the entire results. which includes pressure so you can determine trend. That would be a lot of memory as the number of stations grow.
No promises, Peter. Yes, it can be handy for troubleshooting, but the cost of the way we’re doing it doesn’t justify the benefit (especially since you can get easily with a single API call).
Even caching only 180 records for 10,000 stations is costly. What happens at 50,000?
No, I appreciate that. As Gary said, it’s going to get out of hand pretty quickly.
So cache three hours of data, but keep 24 hours worth of observation counts.
You don’t keep the count. You query for the count. With the cache one simply queries the cache length. Otherwise one makes an additional call at cost which slows down everything.
Yes, we could do that.
Or the number of missing packets during the last 24 hours.
Missing packets would cover this need perfectly.