-
Many thanks. Plenty of ideas to try there. I'll implement what you suggest and report back what happens when it fails again.
Fisu-
Just spotted this:
Fr L#60 function setCurrentUsage() {
Here is a likely spot. There are two division equations. If the divisor is ever zero, a divide by zero error will be thrown. Place the try/catch just inside this function wrapping all, or create two separate to isolate. Maybe a system call to time is not completing timely.
Is L68 an acceptable practice? (combining a float with string text 'e' to return a number inside round?)
parseFloat() or parseInt()are required to provide the Math object with a valid number.
orhttps://www.w3schools.com/jsref/jsref_toexponential.asp
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math
"Math is a built-in object that works with the Number type"
Could the const keyword be blocking a later assignment to that corresponding declaration.
Try changing all const to var to test. Not likely, but worth a shot.Add a clearWatch() in every catch to immediately stop execution. Label each with a useful descriptor like a line number. Hopefully there will be enough previous console.log detail prior to the clearWatch() call to review.
Run time debugging is a challenge and can be a real pain, . . . just waiting.
Robin
Sat 2019.08.10
So that you are not waiting, wondering,
Did you catch this post?
I'm not able to assist as we don't have that type of meter here in the US. However, have you attempted to go back to the original source that Gordon references in #4 and give that a go?
Are you able to restart and continue, e.g. this is only a run time issue after a period of time, or are you forced to reboot/re-upload?
Is it possible there is a counter or something related to the date that reaches an upper limit, then causes an over flow or error? Could placing that section inside a try/catch help in identifying a possible cause to investigate further?
Plenty.
Wow, I would expect one or the other, so it appears that
setWatch()is no longer seeing edges. It would appear that functionupdate()is stuck in an endless loop. To check, place anotherconsole.log()outside of the try/catch in #9 with an additional counter, then monitor. Will/may take a few days before halting, as you pointed out. Not sure if this would work, but at that point, is it possible to block copy that #9 on the left-hand console side of the WebIDE and see if pulses can then be detected? e.g. Espruino is still running and the issue IS in theupdate()function.Try placing a try/catch block(s) inside the update function to see if errors can be trapped, rather than bubbling up and possibly missed.
As a last resort, pepper the entire flow with
console.log()statements and see which one is last recorded.