@CraigWeb We just tried to make this change and I noticed a couple of things.
There is no option for setting intervalLoggingType once you've set loggingType to "Interval and when point value changes" via the GUI.

We ended up just changing the JSON and pushing that out, which it seems to have taken the changes.

Also interesting, when hitting the API endpoint for data point details...if the point is configured as ON_CHANGE_INTERVAL it does not return a key for "intervalLoggingType" nor is any value for any keys set to "AVERAGE" but I certainly do see those for points configured as "INTERVAL"

I honestly always assumed the way ON_CHANGE_INTERVAL worked was it logs on changes and the current value once per minute, I had no idea this would be averaging over that minute and then recording the average.

Anyway...I'll let you know the results, just wanted to give that info.

@Xof1986 that is expected. The events system uses the concept of 'user events'. When an event is raised every user that has permission to see the event gets their own user event stored in the database. This is not ideal but was used so that a single user could silence an event for themselves and not effect anyone else.

To make a long story short, old events will not be visible to a new user because they will not have any user events for events that happened before they existed.

We are planning to remove this for Mango 4.0 but this is how it works currently.

Sure!

{ "xid":"EH_964391", "alias":"", "handlerType":"EMAIL", "eventTypes":[ { "sourceType":"DATA_POINT", "dataPointXID":"siteName_Error_Log", "detectorXID":null } ], "activeRecipients":[ { "recipientType":"MAILING_LIST", "mailingList":"ML_277765" } ], "sendEscalation":false "escalationRecipients":[], "sendInactive":false, "includeSystemInformation":false, "includePointValueCount":10, "includeLogfile":false, "customTemplate":null, "additionalContext":[ ], "script":null, "scriptPermissions":{ "scriptDataPointReadPermission":"", "scriptDataPointSetPermission":"", "scriptDataSourcePermission":"" }, "disabled":false }

I did already blow them out of the system, I just happen to have a bad tab habit so it was still in Np++.

Yes. We also fixed it for that, and the active recipients array too (in the eventual 3.6 release).

Hi Xof1986,

There are not any such options builtin currently. You could hack it up by calling model.clear(); in the script body of the email event handler to make the FTL file fail to process, and then the email will not be sent. I see an easy way to put this into the script, at least, so that one could detect if they didn't want to send an email for whatever reason they could return. Perhaps mitigating floods of emails with an explicit timer setting is common enough that it would warrant being outside the general purpose script body for simplicity.

It sounds like a script like this would prevent email in the current release in your situation, but it will produce an error in the log file,

var values = p.last(10); for(var k = values.length-1; k > 0; k+=1) { //> 0 to not include the current value if( values[k].booleanValue === false && p.time - values[k].time < 60000 ) { model.clear(); //Happened within 1 minute, cause an FTL error instead of another email return; } }

It would be even easier if you set a point from the script body whenever you sent the email, then used that point's timestamp in the email handler to see if you should clear the model.

I will ensure that a better way to prevent emails from sending using the script makes it into 3.4.2, since it should be very simple to do.

Edit: I have added the ability for a script on an email handler to return CANCEL; or return UNCHANGED; to prevent sending the email. I suspect it will be a few weeks before we release 3.4.2 unless major bugs are discovered.

Having rerun my test on a 3.3.4 instance, yes I believe we fixed it in the development of 3.4, which should be out fairly soon.

https://github.com/infiniteautomation/ma-core-public/issues/1236

Hi fishfacs, no problem at all!

You can use

Mango/overrides/web/modules/excelReports/web/ftl/

which will persist upgrades.

Phil,

I restored all of the incrementals up until the deletion occurred since everything since then would be stored on the ES devices we've deployed so I wasn't worried about the most recent stuff.

I did not attempt what you suggested since restoring them one at a time worked. After restoring around 10 I would run in to a concurrent error. I would reboot and then pick up were I left off. Everything seems to have gone well and I don't appear to be missing anything.

Thanks for your help and suggestions.

@terrypacker
Thanks Terry, I look forward to the feature making it in!

I was previously avoiding using the suffix since it is tied to the Property Template. I'll go ahead and fine tune the property templates moving instead of using the generic one that I had made.

Thanks as always guys!

Ed

Thanks again Philip.

I'll need to do a lot of reading before I feel confident with scripting and calling the API.

I thought that the Excel report was a lot more work then it really was. I just created a template with a ton of extra columns and I can change the points accordingly every time. I originally thought I would need to create a new template every time I needed new points but that is clearly not the case in my situation.

Thank you!

Success!

Deleting the database did the trick.

Thanks a ton Phil!

This issue can be tracked on GitHub https://github.com/infiniteautomation/ma-core-public/issues/764