Yes, we are having the same issue, it is logging but all at the same time and you can see the errors in the log. I am hoping someone can help us.
Here is my sheet showing all the same times.
Just as a data point - My sheets are all working - I have 6
What does that mean? How do I fix it?
It means that mine is working and that it isnāt happening to everyone. If I were in your shoes I would try making a new sheet. You can always save your old data.
My issue is, this is the 2nd time in 1 week that I would have to create a new sheet. There has to be a root cause to this.
Well thatās why I offered my data point. Iāll move along.
1 Like
Greg, my apologies, I do appreciate the help. It is just frustrating.
Meanwhile, you might put LastTime in your script or maybe another timescript in the GAS script, as I mention above.
As I have written numerous times in this thread, Iāve never completely trusted the Time variable because it depends on more than just Time. (I quickly saw the Time problem when first trying this Logger and finally got my alternate fields to work June 2016 within a few weeks of using it.) Reading the code you can see that unusual events can cause what you see and essentially make it it incorrect. (It does not get updated across loops in certain situations.) It should not have been set up that way, or at least, one must also have some other time measure if you want Time to be like that. In which case, itās name should be but more like āMost Recent Non-Abend Loop Time Startā (a ridiculous field name, but now you see how itās more accurate).
If something is measuring time, it should measure time correctly. Or else you get what we see.
Have you done this, can you share the script, I donāt write code, so have no idea how to change it.
Greg, thanks for stepping in. Yes, it is really useful to know itās not happening for everyone. At least we know it didnāt suddenly break for everyone, but is something more specific. If anyone else is checking their log -
As I said, I saw it all the way back to the wee hours of 6/22 A.M. (Eastern time). Just glance at your Time column to see if there were repeating values. They really stand out. It only takes a quick glance.
Jason, please be following links people are giving you. Look at that message I put before yours, as I asked.
As I said here a year ago, I have never been good enough with Groovy to understand the overall structure of the CSchwer Logger code, and rewrite it. Although I even got a real GAS expert to rewrite the GAS script as explained here (but it was still over my head, and he didnāt know ST per se, so it was not completely functional).
So anyway, all I have been able to do is stick some things in, instead of rewriting it. I wouldnāt dream of trying. I just donāt have the time to become good at Groovy or Javascript.
To answer your PM: Putting in LastTime or my GAS timestamp wonāt fix Time itself. But I donāt know how to fix Time, and no one else has stepped up. Meanwhile, LastTime (and the GAS time) have never suffered from the error that Time has always suffered from.
So I have both. Most of the time it means I basically have a FirstTime and a LastTime for each row. But sometimes it means I only have LastTime, plus confirmation that Time isnāt working right.
I personally consider LastTime my ārealā time variable, shrug.
ok, so then I can change my graphs to use the last time and that should hope fix the issue does that sound correct?
It doesnāt fix āTimeā. It does provide another time variable you can use, which will not have the problem that Time does. Itās not exactly the same as Time because it is the time that your last sensor reported. Whereas Time is the time that the current CSchwer iteration started (unless stuck, as weāre experiencing).
Just so itās clear: If your reporting period is 10 minutes, then LastTime will ordinarily be 10 minutes after Time. Itās never completely consistent down to the second because it depends on when the last sensor reported (so if you donāt have many, it may be weird). And there are a ton of little processes to go through, and sometimes it varies by minutes. But if you wanted, you can relate your old data to your new data this way (10 minute difference).
I canāt speak for anyone else here, but I myself would not (and have not) ever have relied only on Time, knowing it wonāt update if certain conditions are met.
Meanwhile, it is possible someone may either find a way to fix whatever is the current issue with Time, or completely update the CSchwer script so it never suffers from that again.
Indeed, I have a whole handful of fixes and improvement to the CScwher Logger Iād like to see. Some of which I implemented myself on my own copy. Maybe some of them could be done if it were ever updated.
But for right now, a workaround is to use LastTime.
1 Like
I revised the previous message to clarify things. Please read it again if you already read it (before I posted this). But let me add something quickly here:
LastTime is the time that your most-recent sensor data was received. So if you have little data in a period, it will not be toward the end of the period. And if you have NO data, you will not have a LastTime. I myself have 25 devices and some 100 sensors so I am getting several things a minute (and my Log interval is 10 minutes), so itās not an issue for me. But it may be for you.
I also have code that timestamps the GAS (spreadsheet) side. That stamp WILL always be reported, no matter what. (As long as there is an output row, of course.) And is also a completely separate/independent time source, which is nice for data quality assurance.
1 Like
Thank you for all your help, I really appreciate.
Would anybody have an idea on how to alter the main code so I can choose what data goes in each column?
Actually Jason, it doesnāt matter - the Google Apps Script (GAS) on the spreadsheet is smart enough to look for column name matches.
In other words, just move it anywhere you want. GAS will find it.
Thank you, just did it, working now. Again, thank you for all your help.