I have turned on access, and yes, this email is good.
None of the rules that I had posted which used location / TemperatureF work anymore. I’ve had variations of these rules running for weeks. The rules still show as “enabled.” So it is not an issue with just posting the rules, the system is no longer executing the rules that had been posted.
ok, thank you for the information, @mrfitz98
We’ll check more details with the engineering team and get back to you.
Over the weekend I attempted to post the rules with location /TemperatureF and each time it failed with the “One or more invalid capabilities in body” error.
Monday morning I tried again and it also failed. Monday afternoon I tried again and was able to post the rules successfully.
This stopped working Friday, and started working again Monday afternoon. All rules I had which used TemperatureF as a condition stopped working. It wasn’t just that I could not post rules, the ones I had posted stopped working too.
I find it very disturbing that a SmartThings managed capability can just stop working for an individual location (which is what I think happened based on the fact that others in different locations did not have this problem.) Obviously SmartThings should not be trusted with anything critical.
Hi, @mrfitz98. This is a little confusing, does it mean that what started to work on Monday is just the creation of the Rule but the functionality is still incorrect?
It is strange that it is only happening in one location and to you as @orangebucket mentioned he had no issues with his Rules.
Friday I could not post rules that were using that capability.
Rules that had previously been working fine that had that capability stopped working.
Saturday I could not post rules that were using that capability.
Rules that had previously been working fine that had that capability were not working.
Sunday I could not post rules that were using that capability.
Rules that had previously been working fine that had that capability were not working.
Monday morning I could not post rules that were using that capability.
Rules that had previously been working fine that had that capability were not working.
Monday evening I was able to post a rule using that capability.
Rules that had previously been working fine that had that capability were now working.
On a related question, where do I get the list of attributes associated with “location”?
Thanks
Henry
You have to drill down into the API reference. It ends up saying:
attribute
required string (LocationAttribute)
Enum: "FineDust" "FineDustIndex" "Humidity" "Mode" "Security" "Temperature" "TemperatureC" "TemperatureF" "UltraFineDust" "UltraFineDustIndex" "Weather" "WeatherAlertSeverity"
Unfortunately the possible values don’t seem to be documented.
Following this thread I´m trying to use some of these values in a rule to write to a tile (using @Mariano_Colmenarejo ‘s Number Field from his Virtual Devices) to compare with my home AirQ sensor values. Triggering from changes in location UltraFineDust value I can write without problem from my PM2.5 dust sensor but can’t find the syntax to write the location value. Unable to see how to use `LocationAttribute’ string you mention here - don´t know if there are any examples or documentation anywhere.
Trying as an alternative on a text field the rule is accepted but, logically being numeric fails - on the API browser Execute button it shows failure but I do see the values, so they are being retrieved. Any ideas on this one? Thanks
The code I’m trying, but the API browser returns “operand not valid for operation” is
{
"if": {
"changes": {
"operand": {
"location": {
"locationId": "MY LOCATION ID",
"attribute": "UltraFineDust",
"trigger": "Always"
}
}
},
"then": [
{
"command": {
"devices": [
"221eb0e5-a898-4f7e-b8cd-e0329371d7e8"
],
"commands": [
{
"component": "main",
"capability": "legendabsolute60149.numberFieldOne",
"command": "setNumberFieldOne",
"arguments": [
{
"device": {
"devices": [
"MY PM2.5 SENSOR ID"
],
"component": "main",
"capability": "fineDustSensor",
"attribute": "fineDustLevel"
}
}
]
}
]
}
},
{
"command": {
"devices": [
"221eb0e5-a898-4f7e-b8cd-e0329371d7e8"
],
"commands": [
{
"component": "main",
"capability": "legendabsolute60149.numberFieldTwo",
"command": "setNumberFieldTwo",
"arguments": [
{
"location": {
"locationId": "MY LOCATION ID",
"attribute": "UltraFineDustIndex"
}
}
]
}
],
"sequence": {
"commands": "Serial",
"devices": "Serial"
}
}
}
],
"sequence": {
"then": "Parallel",
"else": "Serial"
}
}
}
Curious, but it seems to choke on the number field device. When I tried to set the number field using the location/UltraFineDust I couldn’t publish it, but when I changed the device to the virtual text field device I was able to publish it.
{
"name": "Location - test",
"timeZoneId": "America/New_York",
"actions": [
{
"command": {
"devices": [
"2af82236-e49f-47f2-8555-cc7d902edef7"
],
"commands": [
{
"component": "main",
"capability": "legendabsolute60149.textFieldOne",
"command": "setTextFieldOne",
"arguments": [
{
"location": {
"attribute": "UltraFineDust"
}
}
]
}
]
}
}
]
}
The UltraFineDust value is a decimal, not an integer, so maybe that had something to do with it?
Exactly, but it doesn’t write the value to the field.
I have tried it with the UltraFineDustIndex which is an integer and the result is the same. When (for the purpose of testing) I changed the trigger, published and clicked the Execute button in the API browser I get
{
"actionId": "75cc0930-8df0-4b42-8e4f-5e11ef7c5cde",
"if": {
"result": "True"
}
}
{
"actionId": "7f6fa2a6-80fe-4d6c-b955-cdc8862c7231",
"command": [
{
"result": "Success",
"deviceId": "MY PM2.5 SENSOR ID",
"component": "main",
"capability": "legendabsolute60149.numberFieldOne",
"command": "setNumberFieldOne",
"arguments": [
184
]
}
]
}
{
"actionId": "efbd6452-408b-49d3-8b05-cb31e910a46a",
"command": [
{
"result": "Failure",
"deviceId": "9834fba7-6fdf-4b72-8436-aa957b7d9865",
"component": "main",
"capability": "legendabsolute60149.textFieldTwo",
"command": "setTextFieldTwo",
"arguments": [
2
]
}
]
}
So I suppose the problem is arguments.
Digging in a little further I was able to update the textfield device with the value from location/mode, so I think we have some kind of value mismatch.
{
"actionId": "27b3f1d0-447f-407b-81fb-b39e1303bc76",
"command": [
{
"result": "Success",
"deviceId": "2af82236-e49f-47f2-8555-cc7d902edef7",
"component": "main",
"capability": "legendabsolute60149.textFieldOne",
"command": "setTextFieldOne",
"arguments": [
"eb4119f3-2cd1-4712-95dc-e123fdea832e"
]
}
]
}
1 Like
Yes I’m sure you’re right. I tried using the location / weather attribute and that writes and updates “Clear”, “Cloudy” etc perfectly in the text field.
The question is why location numeric values are not understood. Would like to understand how LocationAttribute that @orangebucket refers to is used
Thanks for your help.
All my encounters with arguments have been based on trial and error and hoping for the best. I never know when I need a type key and whether it should be a JSON type or the type used in the capability. And that’s just with simple arguments. When it comes to including things like device or location attributes I really don’t know what works and what doesn’t. Presumably it depends on what the developers chose to allow, which is anybody’s guess.
But I’m new to rules, so if more experienced users don’t know, I for sure have no idea on syntax for arguments, and the worst is I cannot see any documentation on this. Which is frustrating for anyone, not just me, trying to be a bit creative with rules.
Been having a good look at this and trying using LocationAttribute but I can’t find the way to write to a numerical field, so I’ll tag @nayelyz and @AlejandroPadilla to see if someone can find a moment to look at it and we can get some help.
No hurry, but thanks in advance!
Hi @Johnnybegoode, give me some time to check it, but for the moment you can find an example of arguments here Help with format for Dimmer and API - #2 by nayelyz
1 Like
Thanks for your reply Alejandro. I’ve taken a look at the post you mention but it doesn’t help in my case, so I’ll wait for you to find a moment to look at my example. TIA
I’m checking the arguments with the team, also I was checking the rule on this post and I’m no sure about somethings, as far as I saw you are trying to sent a value on the attribute numberFieldOne but I’m no sure about the next.
- Where you are opting for UltraFineDust attribute
- Where do you get the value for the trigger?
In my case example Cannot post rules with location capabilities - #20 by Johnnybegoode I am using changes in the value of the location attribute “UltraFineDust” to trigger writing the value of my sensor attribute"fineDustLevel" to numeric field 1, and to write the location attribute “UltraFineDust” to numeric field 2. It triggers perfectly as (if I eliminate the location command to enable me to post the rule) the sensor value continually updates on the numeric field.
The attributes available for location are from the API Reference, found by another contributor earlier in the thread.
“UltraFineDustIndex” is one of these, but to avoid the team having to ask you so many questions we can try with any of these numeric location values, e.g temperature.
To make my question more straightforward, what is the arguments syntax to write any one of these values?
With any sensor device, the syntax is -
How do we write in the case of a location attribute? I´ve tried this but it doesn´t work -
Thanks for your time Alejandro.
Thank you for the information, after talking with the team we found a bug related it, a report is already created, and as soon as I have an update I will inform you.
1 Like