I have a question regarding the alert trigger time in tradingview. In the Pine Editor, I set the strategy parameter as calc_on_every_tick=false and process_orders_on_close=true. However, when I check the {timenow} in the alert message, I found some trigger time is around hh:mm:20 ~ hh:mm:30.
For my understanding, they should be closely around hh:mm:00. Does anyone know the reason? Thank you.
Related
Beginner Level User
I am trying to create a flow that triggers when an item is created in a SharePoint list. When the conditions in my flow are met I want to look for available meeting times for the group and then book the first available with 100% confidence of all attending. I figured out how to find the times and use the compose action. The issue is that I have set the "max candidate" to 1 thinking that would only return one option for the output. When I add the "output" to the create event action I get an error. I am so new to this I don't really know what is wrong. Below is a screenshot of the flow and the error. I would appreciate any tips or advice that can help me figure out where I am going wrong.
I have set up a Grafana alert, that alerts when my values in a graph reaches a specific value.
And that value was reached a month ago and ever since then the state has been "ALERTING".
I obviously want to reset this state to "OK", since the incident happened a month ago and has been resolved.
Any idea how to do that?
I've taken some screenshots of the graph/panel and the settings for the alert, so you can see, what I've set it to.
The main goal is to get a alert everytime the values reach over 468.
Well it is obvious and I guess you just get better at Grafana when trying...
I've found out that you should simple go to the page "Alert Rules" and from there pause and then restart the alert.
When you re-enable it it will change status from "alerting" to "pending", the alert will then check after some time (check what time you've set it too) and if the query no longer calls the alert, it will change to "OK", if not - it will again send out a new alert.
Grafana should normally do this itself - but I've experienced that I've had to manually do this.
Should you not have this possibility - meaning that the query should not call the alert, but should show "OK" and it instead keeps showing "Alerting", then I couldn't find another way around than to delete the alert and set it up again. Not the best solution, but pausing and re-enabling didn't work and I haven't had any difficulties since.
If anyone have had the same experience and found a better solution, then please feel free to post it.
I can also see that this has been a bug/known error as stated here
I want to cancel all my events; I have checked the following topic -
Omnet++, How can I get list of all scheduled events of a module?
But in this link author explains how to do it in OMNeT++ for lower version.
I've also used getFES() instead of getMessageQueue(), andcFutureEventSetinstead ofcMessageHeap. But the problem is that the input value of the function {cancelAndDelete(cMessage)}and FES members are cEvent.
Thanks a lot in advance.
cause no one answer to my question I find out a way to solve my problem. I'll share it maybe it will be useful for some one else.
first point : we can't cancel events made by a module with another module;
second : it's more easier to handle our events and our schedule and CancelandDelete them whenever we want;
I have an Oracle Forms 11 g application running on Weblogic server. The default form/login page has a few PL/SQL triggers that simply will not fire. The rest of the configuration seems successful.
Can anyone give me pointers as to where to start looking?? Thanks in advance.
As their name suggests, triggers fire when something triggers them. For example,
a WHEN-BUTTON-PRESSED trigger is triggered by pushing a button
a POST-QUERY trigger fires after executing a query in a data block
a WHEN-NEW-FORM-INSTANCE trigger fires when the form is being run
and so on.
Therefore, make sure that triggers really are triggered. The fact that you have them doesn't mean that they'll run, just because.
In order to find that out, you have two options:
run a form in debug mode:
in one of the triggers (for example in a WHEN-NEW-FORM-INSTANCE) set a breakpoint by right clicking its left margin (you'll see what to do next)
then run the form; that green toolbar icon you use to run it shouldn't be used, but the one next to it, with something reddish on it
as soon as execution gets to the breakpoint, it'll stop, you'll be transferred to Forms Builder, a debug console will open and will let you navigate through the rest of the code step-by-step
do that, and you'll know what's going on, i.e. whether those triggers are called and what they do
as of you being suspicious: did you, by any chance, put some exception handlers that use WHEN OTHERS THEN NULL or something similar? If so, get rid of them. Even if an exception is raised (such as NO_DATA_FOUND or TOO_MANY_ROWS, just to mention two of the most popular and frequent ones), THEN NULL will silently mask it
another one is to put MESSAGE calls into the triggers, such as
begin
message('running WBP trigger: step 1');
... the rest of your code goes here
end;
Doing so, message-after-message will raise an "alert" on the screen (as you'll have to click OK that you saw what it said), and you'll quickly see which triggers fired and which did not. Then investigate it further - debugging described previously will help.
If none of that helps, you'll have to describe what's going on, but this time providing some more info. What you wrote isn't very descriptive. Anyway, best of luck.
How do I throttle an Elasticsearch Watcher to one alert per event. If an error shows in the logs the watcher will fire until it's acknowledged.
I only want alerts for new errors not a time throttle.
I have found found a reasonable solution for this matter here.
I changed the interval of the watcher to 20s. Then I added a filter for records that are older than 25s.
It does only send one notification per record before it leaves that 5 second window. But I have noticed that this is isn't perfect. It does miss a couple of records but for the most part it works to a satisfactory level.
I added this just in case anyone needed it. If there is a better answer please let me know. I hope this helps.