• Recent
    • Tags
    • Popular
    • Register
    • Login

    Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

    Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website Mango 5 Documentation Website

    Using Persistent TCP points in script calculations

    User help
    2
    41
    18.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      psysak
      last edited by psysak

      Huh, I'm getting odd results Phil.

      0_1516119104019_MangoData.PNG

      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.

      1 Reply Last reply Reply Quote 0
      • phildunlapP
        phildunlap
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • P
          psysak
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • phildunlapP
            phildunlap
            last edited by

            Yes, values in the history sync are processed oldest to newest.

            I wouldn't expect that cron to change anything.

            1 Reply Last reply Reply Quote 0
            • P
              psysak
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • phildunlapP
                phildunlap
                last edited by phildunlap

                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.

                1 Reply Last reply Reply Quote 0
                • P
                  psysak
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • phildunlapP
                    phildunlap
                    last edited by

                    Do you call to LOG.debug("I'm here in my script, doing this."); at all? Or, any other log level?

                    1 Reply Last reply Reply Quote 0
                    • P
                      psysak
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • P
                        psysak
                        last edited by

                        OK so it's 100% that context point.
                        Here is how the log looks without the context point

                        ubuntu@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

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post