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

Setting a value using the context timestamp


  • I am creating a meta point history and during the script I also set another point value at the timestamp of the metapoint's CONTEXT. This works in real time but I do not believe this is working when re-creating history If I set another point value it does not necessarily log correct? The script sets in the scripting window and point is logging ongoing updates with current timestamps however when doing a history with the primary meta point point, the secondary point context does not get logged and this is necessary for the dataset and I don't know how to do this?
    this is run from point1
    var xid = "DP_631ace3f-2e9d-43ed-9ba6-b05a91c580fc"; //point2
    var dataPoints = DataPointQuery.query("eq(xid,"+xid+")");
    var timestamp = Number(CONTEXT.getTimestamp());
    dataPoints[0].runtime.set(Building_Total_KWatts/counter,timestamp); //point needs to log this when doing history on point1 ? only works realtime.


  • I think this approach is convoluted and it's cleaner to make a copy of the primary meta point with the different calculation and that creates the right history a lot simpler. It is doubling the script but I do not see another way to get the history to work.


  • Hi Phillip,

    Thanks for bringing this to our attention. It's producing a class cast exception currently, so at least it doesn't set out to the device each time. One would expect it to just unconditionally add that value to the set point's history?


  • This will be resolved in the upcoming 3.5 release, where calls to set() from a history generation will result in storing that value in the database, but not sending it out the device.