I wanted to set the holding registers of a Modbus Relay to toggle devices.
I know the parameters, registers and values which have to be set, but the CEP operation is not working.
I have tried different methods of indicating the objects.
select
"PENDING" as status,
9716636 as deviceId,
{
"deviceName", "Modbus Relais",
"description", "Relais-Status auf CLOSE setzen",
"c8y_setRegister.input", "false",
"c8y_setRegister.address", "1",
"c8y_setRegister.startBit", "0",
"c8y_setRegister.noBits", "16",
"c8y_setRegister.ipAddress", "",
"c8y_setRegister.value", "256",
"c8y_setRegister.register", "2"
} as fragments
from MeasurementCreated e
where getNumber(e, "c8y_Temperaturecy.T.value") > 2
but the register is not being set
solved by myself: c8y_SetRegister --> s needs to be uppercase
Related
I'm trying to migrate chatbot to use newly introduced Assistant API v2.
My chatbot infrastructure includes Middleware services which modifies the context after getting the response from Watson. In some case I used to remove particular properties from the context and it worked fine. However I noticed that after migration to API v2 this approach does not work anymore as the deleted properties are somehow stored on Watson side.
For example I received following context from Watson:
{
"assistantId": "---",
"sessionId": "---",
"messageInput": {
"Text": "Some text",
"Options": {
"Debug": "true",
"ReturnContext": "true",
"Restart": "false"
}
},
"context":
{
"Global": "null",
"Skills": {
"AdditionalProperties": {
"main skill": {
"user_defined": {
"id": "23",
"description": "Dont know"
},
"system": {---}
}
}
}
}
}
Then I remove 'description' from the context and send request to Watson once more. Surprisingly 'description' is still there with the same value ('Dont know').
Possible solution would be not to remove a property but to set it's value to empty string. But even in this case my dialog does not work correctly as Watson somehow stores the point in dialog it was visiting previously (or not, these are my guesses). I assume it might be related to system.state property which stores an encoded state of the dialog (again - or not).
My question is why is dialog behaving this way?
How does it store the context information so I can't remove properties from user_defined context?
And how can I reset dialog state to initial keeping the same conversation_id (session_id)?
P.S. I'm using Watson API v2: 2020-04-01
I'm trying to write a CEP rule that would take all the existing ACTIVE alarms and increase a specific fragment bike_alarm.priority by 1 every minute. This is the whole structure of alarm:
{
"count": 1,
"creationTime": "2018-07-09T15:30:20.790+02:00",
"time": "2014-03-03T12:03:27.845Z",
"history": {
"auditRecords": [],
"self": "https://cumulocity.com/audit/auditRecords"
},
"id": "1024",
"self": "https://cumulocity.com/alarm/alarms/1024",
"severity": "WARNING",
"source": {
"id": "22022",
"name": "01BIKE_STATION_NORTH",
"self": "https://cumulocity.com/inventory/managedObjects/22022"
},
"status": "ACTIVE",
"text": "Bike disconnected",
"type": "bike_error_01",
"bike_alarm" {
"priority": 10
}
}
This is what I managed to create (based mainly on this question):
create schema Alarm as Alarm;
create schema CollectedAlarms(
alarms List
);
create schema SingleAlarm(
alarm Alarm
);
#Name("Collecting alarms")
insert into CollectedAlarms
select findAllAlarmByTimeBetween(
current_timestamp().minus(100 day).toDate(),
current_timestamp().toDate()
) as alarms
from pattern[every timer:interval(30 sec)];
#Name("Splitting alarms")
insert into SingleAlarm
select
singleAlarm as alarm
from
CollectedAlarms as alarms unidirectional,
CollectedAlarms[alarms#type(Alarm)] as singleAlarm;
#Name("Rising priority")
insert into UpdateAlarm
select
sa.alarm.id as id,
{
"bike_alarm.priority", GetNumber(sa.alarm, "bike_alarm.priority". 0) + 1
} as fragments
from pattern [every sa = SingleAlarm -> (timer:interval(1 minutes))];
the problem is that not all alarms are founded and even those that are the incrementation don't work, priority is set to null.
Additionally, could you point me in direction of some better documentation? Is this something you use?
In general the esper documentation that you linked is the best place to look for the generic syntax.
In combination you probably sometimes also need the Cumulocity documentation for the specific stuff: http://cumulocity.com/guides/event-language/introduction
Coming to your problems:
You are miss-using a realtime processing engine to do cron-like batch operations. While it technically can be done this might not be the best approach and I will show you a different approach that you can take.
But first solving your approach:
The database queries like findAllAlarmByTimeBetween() will only return up to 2000 results and there is no way to get the next page like on the REST API of Cumulocity. Also if you say you want to handle only active alarms you should use a function that also filters for the status.
Getting null out of a function like getNumber() means the JsonPath wasn't found or the dataType is incorrect (using getNumber for a String). You can set a default value for that case as the third parameter. From you Json that you provided it looks correct though. The syntax errors in your code are copy paste errors I assume as otherwise you wouldn't have been able to deploy it.
In my opinion you should approach that differently:
On each incoming alarm raise the priority after one minute if it hasn't been cleared. Additionally trigger the 1 minute timer again. Like a loop until the alarm is cleared.
The pattern for this would like like that:
from pattern [
every e = AlarmCreated(alarm.status = CumulocityAlarmStatuses.ACTIVE)
-> (timer:interval(1 minutes)
and not AlarmUpdated(alarm.status != CumulocityAlarmStatuses.ACTIVE, alarm.id.value = e.alarm.id.value))
];
You need one with AlarmCreated which will only cover the initial increase and a second statement that triggers on your own schema which is then run in a loop.
In general try to avoid as many database calls as you can. So keep the loop counter in your schema so you only always need to execute the update call of the alarm.
How can i get multiple response on action on google console using dialogflow ?
i simulated on Action on google console but only two responses are showing on it
where as third response are not showing
here is my json response
{
"source": "webhook",
"data": {
"google": {
"is_ssml": true,
"permissions_request": null,
"expect_user_response": true
}
},
"messages": [
{
"type": 0,
"speech": "peter Got around 28 marks in maths. which is ranked 1 among 3 candidate in class 1"
},
{
"textToSpeech": "peter Got around 28 marks in maths. which is ranked 1 among 3 candidate in class 1",
"platform": "google",
"displayText": "peter Got around 28 marks in maths. which is ranked 1 among 3 candidate in class 1",
"type": "simple_response"
},
{
"textToSpeech": "Working",
"platform": "google",
"displayText": "Working",
"type": "simple_response"
},
{
"textToSpeech": "Working 2",
"platform": "google",
"displayText": "Working 2",
"type": "simple_response"
}
]
}
Here is my console output
any help regarding this is much appreciated
Thank you
Regards Saif
Only two simple responses will be accepted as a response. If you want more content you will need to consolidate your text into one of the two responses.
As you can see on the AoG Responses docs, it is specified as a requirement :
At most 2 chat bubbles per turn
So your third bubble won't display, as intended by Google.
As suggested in the previous answer from Nick, you need to consolidate your text and wrap everything in your 2 bubbles. In a simple response, you can line break by adding a \n where needed.
In a Basic Card however, you can access a limited subset of markdown, as stated in the docs link I provided, like that :
New line with a double space
**bold**
*italics*
Rich responses have the following requirements and optional properties that you can configure:
Supported on surfaces with the actions.capability.SCREEN_OUTPUT
capability.
The first item in a rich response must be a simple response.
At most two simple responses.
At most one basic card or StructuredResponse.
At most 8 suggestion chips. (you can add more than 8 also but you will get a warning not an error.)
Suggestion chips are not allowed in a FinalResponse
Linking out to the web from smart displays is currently not
supported.
Hi there I seem to miss some information about Loopback where clause or syntax. My problem is, that I receive an empty array if I try to get a list of matching model instances, does no difference if in loopback api explorer or trhough http api request.
My "subject" model:
[
{
"user": "string",
"semester": "string",
"subject_name": "string",
"subject_relevance": 1,
"subject_details": 0,
"id": "string"
}
]
One Instance of Subjects:
{
"user": "59eef907cc199c1cf8f99296",
"semester": "59eef6f8ebf12e1a37ee898b",
"subject_name": "Mathematik",
"subject_relevance": "1",
"subject_details": "",
"id": "59eef96aebf12e1a37ee898f"
}
My Loopback API Explorer filter:
{"where" : {"semester" : "59eef6f8ebf12e1a37ee898b"}}
My http request:
http://localhost:3000/api/subjects?filter[where][semester]=59eef6f8ebf12e1a37ee898b
The result I receive:
[]
If I try to search for this:
{"where" : {"subject_name" : "Mathematik"}}
or in browser:
http://localhost:3000/api/subjects?filter[where][subject_name]=Mathematik
I reveive the instance correctly or as expected. So I went thrugh the documentation and I strugle to find some hints or solutions to my problem. Can someone help me out or suggest me something to get the right instance back? Do I miss something? Has it to do that these are ID-fields or what is it?
Thanks for any help in advance!!
There are 2 ways to get your records based on where clause
one is by using 'findOne' method
get request
http://localhost:3000/api/subjects/findOne?filter[where][semester]=59eef6f8ebf12e1a37ee898b
Other one is using normal get request
http://localhost:3000/api/subjects?filter={"where":{"semester":"59eef6f8ebf12e1a37ee898b"}}
I am using loopback 4 and I had faced the same issue.
Here is the issue in loopback git
Solution is the add this setting in your #model decorator
#model({settings: {"strict":false, "strictObjectIDCoercion": true}})
Having 3 dropdown pickers in a web application. The web application uses a Restful service to populate pickers data.
The two first pickers get their values from something like /years and /colors. The third one should get its values depending on the settings of the two.
So it could be something like /models?year=1&color=red.
The question is, how to make this HATEOAS-compliant (so that the dev does not have to know the way he should create an url to get the models).
The root / gets me a number of links, such as:
{
"_links": {
"colors": "/colors",
"years": "/years",
"models": "???" }
}
What should be instead of ???? If there was some kind of template /models?color={color}&year={year}, the dev would have to create the url. Is this OK?
Or there could be a link to list of years on each color got from /colors and then a link to list of models on each year got from /years?color=red, but i'd have to first choose color, then populate years and then populate models. Any idea if i want to have the model dependent on both color and year, not just the year populated from color?
Is it even possible in this situation to make it hateoas-compliant?
I have not heard of HATEOAS before, but based on what I just read about it, it seems that it supposed to return links to where the consumer of the service can go forward in the "state machine".
In your case that would translate to the links being "function calls". The first two (/colors and /years) are functions that take no parameters (and return "something" at this point), while the third is a function call that takes two parameters: one that is a representation of a color, the other a year. For the first two having a simple URL will suffice for the link, but for the third, you need to include the parameter name/type information as well. Something like:
{
"_links": {
"colors": "/colors",
"years": "/years",
"models": {
"url": "/models",
"param1": {"color"}
"param2": {"year"}
}
}
}
Note: you can use the same layout as "models" for "colors" and "years" as well.
At this point the client knows what the URL to access the functions are and what the parameter (if any) names are to be passed to the function.
One more thing is missing: types. Although you could just use "string", it will not be obvious that the "color" parameter is actually a value from what "/colors" returns. You can be introducing a "type" Color that describes a color (and any functions that operate on a color: give a displayable name, HTML color code, etc.)
The "beefed up" signature becomes:
{
"_links": {
"colors": {
"url": "/colors",
"return": "/type/List?type=/type/Color"
},
"years": {
"url": "/years",
"return": "/type/List?type=/type/Integer"
},
"models": {
"url": "/models",
"param1": {
"name": "color",
"type": "/type/Color"
},
"param2": {
"name": "year",
"type": "/type/Integer"
}
"return": "/type/List?type=/type/Model"
}
}
}
Note: the path "/type" is used just to separate the types from functions, but is not necessary.
This will interchangeably and discoverably describe the functions, what parameters they take, and what values they are returning, so you can use the right value at the right place.
Of course implementing this on the service end will not be easy (especially with parameterized types, like "/type/List" -- think Generics in Java or templates in C++), but this is the most "safe" and "portable" way you can describe your interface to your clients.