we have to use message topic in WIoTP rules. That is if a certain event is triggered X times in Y mins then trigger an action. I am not able to see an option of selecting the message topic while creating a rule. Can someone suggest how this can be done?
It's not currently possible to select a message topic in the Rules configuration. The documentation for triggering rules when the conditions are met N times in the selected time interval can be found here:
https://console.bluemix.net/docs/services/IoT/cloud_analytics.html#conditional
Related
I see both the terms "alert" and "incident" being used on PagerDuty. What are the differences? How are they related?
When PagerDuty receives a qualifying event (from a monitoring tool, for example), it triggers an alert, which in turn triggers an incident. Multiple alerts can be aggregated into a single incident for triage, which streamlines incident handoff between teams, centralizes critical information, and reduces notification fatigue. Alerts can move from one incident to another, either manually or via an automated process, such as Alert Grouping. Here is more information on it: https://support.pagerduty.com/docs/alerts
I want to create a subscription for an entity and to be notified by context broker after a change of measure after a specific time.
For example if humidity reaches a threshold i don't want to be notified.
But if humidity measurement is changed and reaches or is uppon a threshold for 5 days continuously then i would like to be notified.
Is there any pattern for Orion Context Broker Subscriptions for such a purpose?
Essentially, i would like to avoid being notified after some peaks of a measurement .
Orion is mainly stateless focused in current context and doesn't keep a history of the context, so it can be difficult to set conditions on "time windows" like the one I understand you describe.
However, the FIWARE ecosystem provides components (GEs in FIWARE parlance) that can do that work and interoperate with Orion. In particular, the Perseo Complex Event Processor can connect to Orion as notifications receiver and trigger rules based on time window conditions.
How to configure and use Perseo is out of the scope of this answer but in the above link you will find information about the component, documentation and examples.
Just want to confirm the intended behavior of Axon, versus what I’m seeing in my application. We have a customized Kafka publisher integrated with the Axon framework, as well as, a custom Cassandra-backed event store.
The issue I’m seeing is as follows: (1) I publish a command (e.g. CreateServiceCommand) which hits the constructor of the ServiceAggregate, and then (2) A ServiceCreatedEvent is applied to the aggregate. (3) We see the domain event persisted in the backend and published over the EventBus (where we have a Kafka consumer).
All well and good, but suppose I publish that same command again with the same aggregate identifier. I do see the ServiceCreatedEvent being applied to the aggregate in the debugger, but since a domain event record already exists with that key, nothing is persisted to the backend. Again, all well and good, however I see the ServiceCreatedEvent being published out to Kafka and consumed by our listener, which is unexpected behavior.
I’m wondering whether this is the expected behavior of Axon, or if our Kafka integrations ought to be ensuring we’re not publishing duplicate events over the EventBus.
Edit:
I swapped in Axon's JPA event store and saw the following log when attempting to issue a command to create the aggregate that already exists. This issue then is indeed due to a defect with our custom event store.
"oracle.jdbc.OracleDatabaseException: ORA-00001: unique constraint (R671659.UK8S1F994P4LA2IPB13ME2XQM1W) violated\n\n\tat oracle.jdbc.driver.T4CTTIoer11.processError
The given explanation has a couple of holes which make it odd to be honest, and hard to pinpoint where the problem lies.
In short no, Axon would not publish an event twice as a result of dispatching the exact same command a second time. This depends on your implementation. If the command creates an aggregate, then you should see a constraint violation on the uniqueness requirement of aggregate identifier and (aggregate) sequence number. If it's a command which works on an existing aggregate, it depends on your implementation whether it is idempotent yes/no.
From your transcript I guess you are talking about a command handler which creates an Aggregate. Thus the behavior you are seeing strikes me as odd. Either the event store is custom which inserts this undesired behavior, or it's due to not using Axon's dedicated Kafka Extension.
Also note that using a single solution for event storage and message distribution like Axon Server will omit the problem entirely. You'd no longer need to configure any custom event handling and publication on Kafka at all, saving you personal development work and infrastructure coordination. Added, it provides you the guarantees which I've discussed earlier. From more insights on why/how of Axon Server, you can check this other SO response of mine.
While developing and testing the conversation, IBM Watson Assistant identifies multiple intents and respond to the one with highest confidence level. Sometimes I want it to respond to second intent not the first one because it is more relevant to the current conversation context. For example, if the dialogue contains nodes to handle making transfer or payment, during the transfer scenario the user can say execute which will match both execute transfer and execute payment. So I want Watson to always respond to execute transfer which is the current context even if it identifies execute payment with higher confidence.
So users ask generic questions assuming that the bot is aware about the current context and will reply accordingly.
For example, assume that I'm developing a FAQ bot to answer inquires about 2 programs Loyalty and Saving. For simplicity I'll assume there are 4 intents
(Loyality-Define - which has examples related to what is the loyalty program)
(Loyality-Join - which has examples related to how to join loyalty program)
(Saving-Define - which has examples related to what is the saving program)
(Saving-Join - which has examples related to how to join saving program)
so users can start the conversation by utterance like "tell me about the loyalty program". then they will ask "how to join" (without mentioning the program assuming that the bot is aware). In that case Watson will identify 2 intents (Loyalty-Join, Saving-Join) and Saving-Join intent may have a higher confidence.
so I need to intercept the dialogue (may be be creating a parent node to check the context and based on that will filter-about the wrong intents).
I couldn't find a way to write code in the dialogue to check the context and modify the intents array so I want to ask about the best practice to do that.
You can't edit the intents object, so it makes what you want to do tricky but not impossible.
In your answer node, add a context variable like $topic. You fill this with a term that will denote the topic.
Then if the users question is not answered, you can check for the topic context and add that to a new context variable. This new variable is then picked up by the application layer to re-ask the question.
Example:
User: tell me about the loyalty program
WA-> Found #Loyality-Define
Set $topic to "loyalty"
Return answer.
User: how to join
WA-> No intent found.
$topic is not blank.
Set $reask to "$topic !! how to join"
APP-> $reask is set.
Ask question "loyalty !! how to join"
Clear $reask and $topic
WA-> Found #Loyalty-join
$topic set to "loyalty"
Return answer
Now in the last situation, if even with the loaded question it is not found, clearing the $topic stops it looping.
The other thing to be aware is that if a user changes topic you must either set the topic or clear it. To prevent it picking the old topics.
NOTE: The question was changed so it is technically a different question. Leaving previous answer below
You can use the intents[] object to analyse the returning the results.
So you can check the confidence difference between the first intent and second intent. If they fall inside a certain range, then you can take action.
Example condition:
intents[0] > 0.24 && intents.[1] - intents[0] > 0.05
This checks if two intents are within 5% of each other. The threshold of 0.24 is to ignore the second intent as it will likely fall below 0.2 which normally means the intent should not be actioned on.
You may want to play with this threshold.
Just to explain why you do this. Look at these two charts. The first one it's clear there is only one question asked. The second chart shows that the two intents are close together.
To take actual action, it's best to have a closed folder (condition = false). In that folder you look for matching intents[1]. This will lower the complexity within the dialog.
If you want something more complex, you can do k-means at the application layer. Then pass back the second intent at the application layer to have the dialog logic take action. There is an example here.
Watson Assistant Plus also does this automatically with the Disambiguation feature.
You can train Watson Assistant to respond accordingly. In the tool where you work on the skill click on the User conversations page in the navigation bar. In the message overview you would need to identify those that have been answered incorrectly and then specify the correct intent. Watson Assistant will pick that up, retrain and then hopefully answer correctly.
In addition, you could revisit how you define the intents. Are the examples like the real user messages? Could you provide more variations? What are the conflicts that make Watson Assistant pick the one, but not the other intent?
Added:
If you want Watson Assistant to "know" about the context, you could extract the current intent and store it as topic in a context variable. Then, if the "join" intent is detected, switch to the dialog node based on intent "join" and the specific topic. For that I would recommend to either have only one intent for "join program" or if really needed, put details about the specifics into the intent. Likely there is not much difference and you end up with just one intent.
On Parse (that I now have to leave behind) I had the ability to set multiple channels per installation and then target specific ones in my push notifications.
What is the best way to do this with SNS? At first I thought about topics, but there is a limitation to these.Another problem with topics is that the topic has to pre exist: On Parse you just mentioned a channel and you could then query and filter the Push recipients.
Should I create a similar experience manually using DynamoDB and keep the device token (as a primary key) and then the subscribed channels? This way when I want to send custom push messages I will have to query DB for the specific devices that contain that channel?
Hope someone has already dealt with this before.