As the docs https://developers.google.com/actions/smarthome/traits/fanspeed not say what speed_synonym is allowed (no reference list), and "speed 1", "speed 2" of the example not work, juts "low", "high" work. "1", "2", "3" ... also not work. So the question is what speed_synonym is valid in fanspeed traits ?
Any key and synonyms should work for a particular language for the FanSpeed trait. Low/High work, as per the example, but I've also gotten 1/2/3/4 to work for the speed_name field. You may want to inflate your speed_synonym field to have more synonyms which will trigger.
Related
Ok, new to RESTapi so not sure if I am using the correct terminology for what I want to ask so bear with me. I believe what I am asking about is nested resources in a service but I want to ask specifically about using it for separating a blob of "closely related" content. It may be easier to provide an example. Let's say I have the following service that could output the following:
/Policy
"data": [ {
"name": "PolicyName1",
"description": "",
"size": 25000,
.... (bunch of other fields)
"specialEnablement": true,
“specialEnablementOptions”: { <-- options below valid only if specialEnablement is true
“optionType”: “TypeII”,
“optionFlagA”: false,
“optionFlagB”: true,
“optionFlagC”: false,
...(bunch of other options here)
}
},
{ . . . }],
The specialEnablementOptions are only used if specialEnablement is 'true'. It is all part of this /Policy service so has no primary key other than the policy "name" (and doesnt make sense to have to generate one) so does not fall under some of the other questions I have been reading about nested resources.
It does make it more readable to separate this set of information since there are 12 or so options but, this is REST so, maybe human readability does not weigh heavily here.
I am being told that, if we do it this way, it makes it more complex to work with during POST/PUT/PATCH commands. Specifically, it is being said in my group that if we do this, we should require two calls....one that creates the policy main information then the user must call a second time to PATCH the specialEnablementOptions (assuming specialEnablement is true). This seems kludgy to me.
I am looking for expert advise on what the best practice is.
My questions:
Does having the specialEnablementOptions nested in this way cause a
lot of complexity. Seems to me that either way we have to verify
that the settings are valid?
Does having the specialEnablementOptions nested in this way require
two calls? In other words, can a user not do a POST/PATCH/PUT for
all the fields including those in the specialEnablementOptions in
one call? We are planning to provide a way for the user to do a
PATCH of just the specialEnablementOptions options without changing
any of the first level for ease of use but is there something that
prevents them from creating or modifying all settings in one call?
Another option is to just get rid of the nested
specialEnablementOptions and put everything at the same level. I
dont have a problem with this but wasn't sure if this was just being
lazy. I dont mind doing this if the consensus is it is the best way
to do it....but I also have a second example that is similar to this
scenario but is a bit more complex where putting everything under the parent level is not really optimal (I will show in the next example)
So, my second example is as follows:
/anotherPolicy
"data": [ {
"name": "APolicyName1",
"description": "",
"count": 123,
"lastModified": "2022-05-17-20.37.27.000000",
[{
"ownerId": 1
"ownerCount": 1818181
"specialFlags": 'ABA'
},
{ . . . }]
},
{ . . . }],
The above 'count' is the total number associated to that policy and then there is a nested resource by owner where the count by owner can be seen..plus maybe other information specific to that owner. The SUM(ownerCount) would equal "count" above it. Does this scenario change any of the answers to the questions above?
I appreciate your help. I found a ton of information and reference on when to use or not use nested endpoints but all the examples seem to orient around subjects that seem like they could easily be separated into two resource...for instance whether to nest /employees under /departments or /comments under /posts. Also, they didn't deal with the complexities of having nested endpoints vs avoiding them. And last, if using nesting is unnecessary as a readability standpoint.
VIA Actions Console, not Dialogflow!
After several days I finally finished to create a Quiz that works like this.
Google Mini says: "What is the capital of France? A) Rome, B) Berlin or C) Paris ?"
In my scene i have two conditions.
scene.slots.status == "FINAL" && intent.params.choosenABC.original == session.params.antwort
AND
!(scene.slots.status == "FINAL" && intent.params.choosenABC.original == session.params.antwort)
So here, these conditions check whether the user says the correct letter coming from the session parameter "antwort".
Everything works smooth as long as the user says "A", "B" or "C".
But how can i compare a condition to what the user says?
In the above example i want the user to be able to say "Rome" or "Berlin" or "Paris" and the condition to check these entries.
Thanks in advance!
You have a number of questions packed in there, so let's look at each.
Does input.params.original exist?
In short, yes. You can see the documentation of the request Intent object and you'll see that there is intent.params.*name*.original. Your question seems to suggest this would work as well.
There is also intent.params.*name*.resolved which contains the value after you take type aliases into account.
I found some variables on a Dialogflow forum...
Those only work if you're using Dialogflow and don't make any sense when you're looking at Action Builder.
How to match
You don't show the possible value of session.params.antwort or how you're setting antwort. But it sounds like it makes sense that you're setting this in a handler. So one thing you could do is to set antwort to the city name (or whatever the full word answer is) and set letter to the letter with the valid reply. Then test both against original to see if there is a match.
But, to be honest, that starts getting somewhat messy.
You also don't indicate how the Intent is setup, or if you're using an Entity Type to capture the answer. One great way to handle this, however, is to create a Type that can represent the answers, and use a runtime type override to set what the possible values and aliases for that value are. Then, you can control exactly what the valid value you will use to compare with will be.
For example, if you create a type named "Answer", then in your fulfillment when you ask the question you can set the possible values for this with something like
conv.session.typeOverrides = [{
name: 'Answer',
mode: 'TYPE_REPLACE',
synonym: {
entries: [
{
name: 'A',
synonyms: ['A', 'Rome']
},
{
name: 'B',
synonyms: ['B', 'Berlin']
},
{
name: 'C',
synonyms: ['C', 'Paris']
}
]
}
}];
If you then have an Intent with a parameter of type Answer with the name answer, then you can test if intent.parameter.answer.resolved contains the expected letter.
Adding a visual interface
Using runtime type overrides are particularly useful if you also decide to add support for a visual selection response such as a list. The visual response builds on the runtime type override to add visual aliases that users can select on appropriate devices. When you get the reply, however, it is treated as if they said the entry name.
I'm at a roadblock with this one, I've been trying to find a way to simplify my work so as to avoid using a giant if statement block. I came to the idea that I could use s "Ref" With a "Fn::Join" but obviously it doesn't work or at least not the way I'd visually think it would work.
"Type": "AWS::WAFRegional::Rule",
"Properties":{
"Predicates": [{
"DataId":{
"Ref" : {"Fn::Join" : ["", [{"Ref" : "IpSets"}, "IPSet"]]},
So how I visually see this working is that "Ref" : IpSets is a parameter that we set when uploading the file to CloudFormation. So it will pull down that text, and combine it with IpSet to create something like DevIPSet. Since that's a String after a join, it would come out to be "Ref" : "DevIPSet" and then that would pull the set of IP's I've put aside.
This obviously doesn't work and was reaching out to the community if there is a trick I can use. I have looked into Mapping and can't see to make that work with the dataID either. The only real solution I've found is just using Fn::If and make a giant block but that is ugly.
What you are trying to do, I think, is not possible. Because there is a duplication of tag property.
I can't create a queryPattern containing two Text fields, like so:
"parameters": [
{
"name": "text_a",
"type": "org.schema.type.Text"
},
{
"name": "text_b",
"type": "org.schema.type.Text"
}
],
"trigger": {
"queryPatterns": [
"add $org.schema.type.Text:text_b with $org.schema.type.Text:text_a",
"combine $org.schema.type.Text:text_b along with $org.schema.type.Text:text_a"
]
}
This will always result in a failure to match the intent (for example "add something with another").
However, I can use two Color types: If you change "Text" to "Color" in the above, and say "add red with blue" or "combine auburn along with green" then it matches and fires the intent.
I am creating deep-link intents only (i.e., commands, not a back-and-forth dialog), so I don't think DialogFlow will help me?
I suspect that the problem is that AoG is treating text parameters as "greedy", so a second parameter never matches because the first parameter has captured all the text. You don't see this with specific types, because it does more narrow matching for them.
You may actually try to use Dialogflow - it does work for deep linking Intents, although I don't know if it will behave the same way.
In My social network I want to get the feed for member A , member A is following lets say 20 category/member.
when a category/member(followed by member A) do an activity it is inserted into a collection called recent_activity :
{
"content_id": "6", // content id member A is following
"content_type_id": "6",// content type (category , other member)
"social_network_id": "2", // the action category did (add/like/follow)
"member_id": "51758", //Member A
"date_added": ISODate("2014-03-23T11:37:03.0Z"),
"platform_id": NumberInt(2),
"_id": ObjectId("532ec75f6b1f76fa2d8b457b"),
"_type": {
"0": "Altibbi_Mongo_RecentActivity"
}
}
I want when member A login into the system to get last 10 activities for the categories/member
my problem :
How to get Only 10 activities for all categories/members.
It is better to do it in one query or to do a for loop.
For this use case, I'd suggest to invert the logic and keep a separate object of the last 10 activities for member A that is kept up-to-date all the time. While that solution is more write-heavy, it makes reading trivially simple and it can be extended very easily. I'd like to blatantly advertise a blog post I wrote a while ago about news feeds with mongodb which outlines this approach.
This 'fan-out' approach might seem overly complex at first, but when you think about importance filtering / ranking (a la facebook), push messages for particularly important events (facebook, twitter) or regular digest emails (practically all), you will get one location in your code to perform all this logic.
I think I commented that T'm not really seeing the selection criteria. So if you are "outside" of a single collection, then you have problems. But if your indicated fields are the things you want to "filter" by, then just do this:
db.collection.find({
"social_network_id": "2",
"content_type_id": "6",
"content_id": "6",
"member_id": { "$ne": "51758" }
})
.sort({ "$natural": -1 })
.limit(10);
So what does that do? You match the various conditions in the data to do the "category match" (if I understood what was meant), then you make sure you are not matching entries by the same member.
The last parts do the "natural" sort. This is important because the ObjectId is monotinic, or math speak for "ever increasing". This means the "newest" entries are always the "highest" value. So descending order is "latest" to "oldest".
And the very final part is a basic "limit". So just return the last 10 entries.
As long as you can "filter" within the same collection in whatever way you want, then this should be fine.