Process Event handler to fire external script

[MattFox]

Since that's the case it's likely best you find the causes of them through virtualenv.
If they have env paths, echo them in the bash file. This will tell you if your ssh connection is inheriting all of the required information.

[khuang]

Actually I mispoke - my set point event handler is not firing. It was the old process event handler that was firing that I forgot to deactivate. So now I am trying to set my ssh data point through the set point event handler.

This is what I have for the set point event handler ("MangoES - Trigger" is the SSH datapoint)"

It does not look like the event is firing though because my SSH datapoint is N/A.

[MattFox]

@khuang Is there no information in logs??
Also enable logging on the ssh datasource and tail -f the log file. Would be interesting to see if anything comes through at all.
EDIT: check your syslogs as well.

[khuang]

There isn't anything in the sys logs but tail -f for the session log file of the datasource gives me:

So it does look my test script is running but when I try to flip the bit back to 0 for my ssh data point, it just automatically executes my set point handler again and sets it back to 1. The set point handler shouldn't be activating unless there is a change from 0->1 for my source.

[MattFox]

@khuang Make sure your point handler has normal as 0. also ensure the script to fire box when returning to normal is empty.

[khuang]

@mattfox What do you mean by setting the normal as 0? Do you mean creating an inactive action and scripting return 0?

Is this what you mean:

[MattFox]

No set inactive action to none. From what I gather you've got the event to fire on change.. What's the logic you're after? if something goes high fire this script? Need more info to diagnose how to set an inactive region.
EDIT: Just read above. Get the point in context and check the value,

if ( point.last(1,0)[0].value == 0 && point.value == 1 )
{
 return true; //fire handler
}
return false; //don't fire handler

That way it checks if the point has changed the right way and then only returns true for that; otherwise it returns false;
Ideally just set a high limit and set it to 1. The event will fire on 1 or above and return to normal on zero.

[phildunlap]

Or, if the source point is binary, use a state detector on true and like Fox said, no inactive action.

[khuang]

@mattfox said in Process Event handler to fire external script:

if ( point.last(1,0)[0].value == 0 && point.value == 1 )
{
return true; //fire handler
}

The logic that I am after is that it fires my script but I do not want the scripts to continuously fire.
Right now there are two problems:

1. the set point handler is triggering all the time (the reason why I believe it is triggering all the time is because my set point cannot be set back to 0) and setting my ssh data point to true all the time. It should execute once and be done. Right now the data point is stuck at 1, and I am unable to change it back to 0.
   
2. my script which is in the set command of the ssh data point still is not executing, which is the purpose behind me pursuing ssh datasources and data points

EDIT: I recreated the SSH datapoint, and set point handler and I got the set command to fire but at a 6 second delay. It also looks like the entire MangoES box is lagging at the same rate.

EDIT2: After restarting the MangoES box and deactivating several other data sources that have various polling and triggers associated with it, the CPU reduced to 360% (8 cores). Before the CPU was being hit too hard so the script was not running correctly.

[MattFox]

For your virtual datapoint, if it's set to logging all it'll continuously update/trigger the event.
Set logging to update on point value change only as you only need it to work when it changes between 1 and 0, not 1 and 1.

[phildunlap]

It would depend on whatever event detector has been placed on the point.

[MattFox]

@phildunlap Also true...

[khuang]

Currently for the event detector I have it as "when the state is one". So I guess "when the state is one" means 0 to 1 and 1 to 1?

What if I created another event detector for "when the state is zero" and kill the process that way?

[MattFox]

Let's see a screenshot of your datapoint settings.
From what I gather, you have an SSH source which runs a python script which then sets the value of the binary datapoint. If that point is set to one, fire an event handler.
Does that sound right?

[khuang]

Yes, that is correct.

Here is a screenshot of my virtual datapoint which serves as the source for firing the event handler:

I manually set the virtual datapoint so it only goes from 0 to 1 or 1 to 0, and not 0 to 0 or 1 to 1.

This is my SSH datapoint which gets set by the event handler. I have it get scripted to return true because I don't care what the value of this data point is but just that the set command gets fired:

[phildunlap]

Currently for the event detector I have it as "when the state is one". So I guess "when the state is one" means 0 to 1 and 1 to 1?

What if I created another event detector for "when the state is zero" and kill the process that way?

Can you post the JSON for the event detector / source point? State event detectors will not retrigger the active event handler from repeated samples of the same state, but would retrigger the event if the point or data source were restarted (i.e. saved, Mango restarts, etc)

[MattFox]

Actually yes, the JSON would be better there is still a lot of information missing.

[khuang]

Yes, here is the JSON of the event handler:

{
   "eventHandlers":[
      {
         "xid":"EH_caaac4a3-6ff5-4046-8eaa-0ff5be6a6370",
         "alias":"",
         "handlerType":"EMAIL",
         "eventTypes":[
            {
               "sourceType":"DATA_SOURCE",
               "XID":"DS_2b8b5316-3bd1-4b4e-82d2-c5f00dbd4ba4",
               "dataSourceEventType":"SCRIPT_ERROR"
            }
         ],
         "activeRecipients":[
            {
               "recipientType":"ADDRESS",
               "address":"khuang@cityliftparking.com"
            }
         ],
         "sendEscalation":false,
         "sendInactive":false,
         "includeSystemInformation":true,
         "includePointValueCount":10,
         "includeLogfile":true,
         "customTemplate":"",
         "additionalContext":[
         ],
         "script":"",
         "scriptPermissions":{
            "scriptDataPointReadPermission":"superadmin, user",
            "scriptDataPointSetPermission":"superadmin, user",
            "scriptDataSourcePermission":"superadmin, user"
         },
         "disabled":false
      },
      {
         "xid":"EH_2d361442-9b2e-40ff-82bd-3f85c42d3480",
         "alias":"",
         "handlerType":"SET_POINT",
         "eventTypes":[
            {
               "sourceType":"DATA_POINT",
               "dataPointXID":"DP_d8a89826-e771-4760-ac46-9064a5e3b3d0",
               "detectorXID":"ED_80c9adf7-f1ad-4058-a60a-05a58f53ecf6"
            }
         ],
         "targetPointId":"DP_41011e72-6228-4ae6-a4e3-6fdce7c45ec7",
         "activeAction":"SCRIPT_VALUE",
         "activeScript":"return true;",
         "inactiveAction":"NONE",
         "additionalContext":[
         ],
         "scriptPermissions":{
            "scriptDataPointReadPermission":"superadmin",
            "scriptDataPointSetPermission":"superadmin",
            "scriptDataSourcePermission":"superadmin"
         },
         "disabled":false
      }
   ]
}

@phildunlap You said that the script could get retriggered if I restarted the data source and data point, which is what I was doing. So maybe that was the cause. I was restarting the source and point because I was unable to set the ssh data point in the watch list.

EDIT: I think I see what the problem might have been (with the lagging). When I restart the SSH data source/point, the event handler fires again and launches my script in another session and it does for each time I restart the source/point. And eventually it hoses up my entire system.

[phildunlap]

@phildunlap said in Process Event handler to fire external script:

Can you post the JSON for the event detector / source point?

But no matter, the restarting of the point or source was likely the cause of resending. So, now the issue is that even using SSH you're experiencing those issues with python modules being undefined? What was that post about the Hello World text and the SSH invoking the script about? Or, is everything working now and it was melting from the multiple runs of the script?

[khuang]

@phildunlap It was the melting from the multiple runs of the script which made it appear that the script was not working. Right now everything is working. The command in the 'set command' of my ssh datapoint is firing when the state changes to true for my source whereas it the same command was giving errors in the process event handler so the lesson learned for me is to use a set point event handler when my script uses relative paths and environmental variables.

Only problem now is I need to be careful because each time the source goes to 1, it starts up another run of my script and with 3 of those, my system crashes. Now I just need a way to kill the process when the state changes to false.