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

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

Event Handler not responding to inactive status

  • Scenarios

    1. A time scheduler created that trigger on every hour and trigger off after 10 minutes.
    2. An event under scheduler define with as shown below.
      note: the target should not be needed if execution by script but the program required to put some parameter so I put other datapoints. When test the script if shows success false but the on trigger always executed properly except the inactive event.

    I tried also to use set to static value and define additional context but in this case only the target is changing in on event.

    3.Here the virtual datasource and point use in the simulation
    Note that I make sure that it is settable

    1. Monitor the datpoints details and it trigger on every hour (4:00pm (Set point handler) but never executed the trigger off / inactive value script.

  • Hi Joey Uson,

    It looks like there was an oversight when the additional context was put on scripted event handlers: the context is not set in the inactive script! Oh no! Thank you for bringing this to our attention, it will be fixed in the 3.5 release. In the mean time, this could be put in to get you up an running:

    function ensureContextExists( eventHandlerXid ) { //the XID of the handler running this script
      var eventHandlers = JSON.parse(JsonEmport.getConfiguration("eventHandlers") ).eventHandlers;
      for( var k = 0; k < eventHandlers.length; k+=1 ) {
        var eh = eventHandlers[k];
        if( eh.xid !== eventHandlerXid )
        for( var j = 0; j < eh.additionalContext.length; j += 1 ) {
          this[ eh.additionalContext[j].contextKey ] = DataPointQuery.query( "eq(xid," + eh.additionalContext[j].dataPointXid + ")" )[0].runtime;
    ensureContextExists("EH_123"); //Your Event handler XID here
    //Rest of inactive script here

    You could define that function in a global script if you want, and then invoke it from every inactive script. Sorry for the inconvenience. Also it appears the NPE from refering to the variable name that doesn't exist is making it to stderr, so be aware that would be the case again if you use this function and one of the points is not running: you will get a null pointer exception when attempting to refer to that point later in the script, and because it's through the old scheduled events module that is printing its errors to stderr, not the log. I will fix that too!

  • Just tested today and I would like only to inform you that it is working , thanks for the support

  • Hey @phildunlap, could you do me a favour and check the advanced scheduler code as well?
    I may be using 3.4.1 and thus you may have fixed it. But when I had a schedule set to inactive, the events still kept firing also.


  • Hi Fox,

    I was not able to get quite the behavior you're describing in that version, but I did notice on the Advanced Scheduler edit page that if you toggle a schedule into the other enabled / disabled state, then modify and save the schedule, it will toggle itself back to the original state. Might that have been what you saw? We will resolve that.

  • Well I toggled it to inactive, but my info logs still kept notifying me of it firing/finishing (i set up both to confirm if I could use it like a flip flop during different parts of the day). maybe it's not actually setting it to inactive outright?

    EDIT: Strange, I implemented it the same way again to see if I would have the same outcome but can no longer replicate it....
    I'll watch closely, but in the meantime, that fix you mentioned will definitely help.

  • I just took a second look and I can see a way to cause what you described, so I am fixing it. It would have required disabling the schedule almost exactly at a state transition. Thanks for bringing it to our attention!

  • Nicely identified Phil, glad I could be of assistance,