Using Persistent TCP points in script calculations
-
Interesting, I'm still getting the same errors as before even though I tried changing the script so it doesn't rely on LOGGED or anything like that. I'm literally pulling the data right out of the database
if(pulse.lastValue().time > my.lastValue().time + 15000) { var list = pulse.pointValuesSince(my.lastValue().time + 5000); for (var i=0; i < list.length; i++) { my.set(list*.doubleValue * pfactor * tfactor, list*.time); } } return UNCHANGED;
Now I get this error, which is the same as before
'MORGUARD': Script error in point "MORGUARD - EO00026SW_BIERMARKTM3": TypeError: Cannot get property "time" of null in at line number 31 in at line number 31Add commentOh well... That was my last attempt, I'll move it all to the edge devices now.
-
The issue is that the meta point doesn't have any values, so
my.lastValue()
is null, and it cannot have a.time
.One can initialize a meta point like this by either setting a value to it, or putting a little handling in the point, like,
if(my.lastValue() === null) { //TIMESTAMP = new Date(2018, 1, 1).getTime(); //When does your point begin? //return 0; //What does it begin at? //Edit: I just remembered, you could also do, my.set(0, new Date(2018, 1, 1).getTime()); //and then carry on with the script. //be sure your meta point is settable! }
-
Noo way! If that's the issue I'm gonna have some kind of egg on my face haha. Classic rookie mistake not validating this.
K I'm going to poke this into all my points and see how it feels about it.
-
I did that on purpose just to see how well you knew your product.......
-
And I wrote
getPointValuesSince
instead ofpointValuesSince
the first time to ensure you had something to correct... yes... :D -
Huh, I'm getting odd results Phil.
And there's time ranges with no issues at all. No errors now though. The only thing I can think of is a timestamp that I'm not aware of which affects the number of data points I get back.
I was hopeful!
My code looks like this now, triggered every 15mins.
if(pulse.lastValue() === null) { return UNCHANGED; } if(my.lastValue() === null) { my.set(0, new Date(2017, 1, 1).getTime()); } if(pulse.lastValue().time > my.lastValue().time + 15000) { var list = pulse.pointValuesSince(my.lastValue().time + 5000); for (var i=0; i < list.length; i++) { my.set(list*.doubleValue * pfactor * tfactor, list*.time); } } return UNCHANGED;
I've turned on TRACE logging for this script, hopefully I can see what's going on.
Saga continues, Empire Strikes Back episode.
-
My first thought, pardon the asking, is if your source point has values for that time period.
Also, my offhand
new Date()
was somewhat off, the month field is zero indexed, so,
new Date(2017, 0, 1).getTime(); //Jan 1 2017 server timezone
-
Hey, absolutely valid question and yes they do have data for those missing chunks. I also did notice that it was a month off but I'm okay with that I don't have any data prior to middle of last year anyway. Script runs every 15 minutes and I enabled the trace logging a while ago so hopefully when I go back and look at it this afternoon I'll see something useful. I forgot to mention as well that I trigger every 15 minutes starting at 2 minutes past the hour that way hopefully everything is synced properly but it shouldn't matter anyway cuz that scription catch any change. I believe you mentioned that the historical synchronisation through this mechanism starts with the oldest date of first is that correct?
-
Yes, values in the history sync are processed oldest to newest.
I wouldn't expect that cron to change anything.
-
Let me ask you this, are execution conditions additive or exclusive? So if I have context update logged, a point is set to update context AND a CRON is setup what happens? I just realized I left a point updating context in that script so am experimenting with that now.
-
Additive-ish; a meta point executing every 15 seconds with four point updates in a minute (to a point that is set to update context, with an update event that has occurred) will execute eight times, unless a point update is at the same millisecond as the cron commanded. Then whichever execution arrived second will not be performed.
-
LOL this is all I get from the TRACE logs for the meta point
INFO 2018-01-16 11:15:46,365 - Data point started
You think more logs might still be buffered and haven't purged to file yet? Or is this all I should get
-
Do you call to
LOG.debug("I'm here in my script, doing this.");
at all? Or, any other log level? -
Ooooohhhh I see, that logging is manually controlled. I thought it was system level logging where it would print stuff out itself. Got ya, I can add some stuff to see what results I get.
-
OK so it's 100% that context point.
Here is how the log looks without the context pointubuntu@ip-172-31-5-12:~/mango/logs$ cat metaPoint-494.log INFO 2018-01-16 16:14:50,747 - Data point started TRACE 2018-01-16 16:17:00,035 - Time:1516137420000 TRACE 2018-01-16 16:17:00,056 - Array size:15 TRACE 2018-01-16 16:32:00,005 - Time:1516138320000 TRACE 2018-01-16 16:32:00,009 - Array size:15
Nice and clean. With the context point in the script I have this mess
INFO 2018-01-16 16:14:35,911 - Data point started TRACE 2018-01-16 16:15:00,649 - Time:1516136400000 TRACE 2018-01-16 16:15:00,672 - Array size:15 TRACE 2018-01-16 16:15:00,700 - Time:1516136460000 TRACE 2018-01-16 16:15:00,704 - Time:1516136520000 TRACE 2018-01-16 16:15:00,704 - Time:1516136580000 TRACE 2018-01-16 16:15:00,704 - Time:1516136640000 TRACE 2018-01-16 16:15:00,705 - Time:1516136700000 TRACE 2018-01-16 16:15:00,710 - Time:1516136760000 TRACE 2018-01-16 16:15:00,710 - Time:1516136820000 TRACE 2018-01-16 16:15:00,710 - Time:1516136880000 TRACE 2018-01-16 16:15:00,710 - Time:1516136940000 TRACE 2018-01-16 16:15:00,710 - Time:1516137000000 TRACE 2018-01-16 16:15:00,710 - Time:1516137060000 TRACE 2018-01-16 16:15:00,710 - Time:1516137120000 TRACE 2018-01-16 16:15:00,710 - Time:1516137180000 TRACE 2018-01-16 16:15:00,711 - Time:1516137240000 TRACE 2018-01-16 16:17:00,003 - Time:1516137420000 TRACE 2018-01-16 16:30:00,671 - Time:1516137300000 TRACE 2018-01-16 16:30:00,686 - Array size:1 TRACE 2018-01-16 16:30:00,688 - Time:1516137360000 TRACE 2018-01-16 16:30:00,689 - Time:1516137420000 TRACE 2018-01-16 16:30:00,689 - Time:1516137480000 TRACE 2018-01-16 16:30:00,690 - Time:1516137540000 TRACE 2018-01-16 16:30:00,690 - Time:1516137600000 TRACE 2018-01-16 16:30:01,102 - Time:1516137660000 TRACE 2018-01-16 16:30:01,102 - Time:1516137720000 TRACE 2018-01-16 16:30:01,102 - Time:1516137780000 TRACE 2018-01-16 16:30:01,103 - Time:1516137840000 TRACE 2018-01-16 16:30:01,104 - Time:1516137900000 TRACE 2018-01-16 16:30:01,105 - Time:1516137960000 TRACE 2018-01-16 16:30:01,105 - Time:1516138020000 TRACE 2018-01-16 16:30:01,105 - Time:1516138080000 TRACE 2018-01-16 16:30:01,105 - Time:1516138140000 TRACE 2018-01-16 16:32:00,000 - Time:1516138320000
Thing just goes nuts...
OK, on to Return of the Jedi