You would use a Set Variable action and choose Expression for the source. Then use the snippet mentioned in the thread further above to filter things… then use the value from the variable you set in your notification.
You can add multiple Timer triggers to a single rule. We don’t currently support ‘Every XX hours’ type of triggers. Some community members have come up with creative approaches to accomplish that, but it’s not something we officially support or recommend.
Check the screenshot from my post. What it’s doing is using the Set Variable action where you will set a variable based on the result of an expression.
This comes after the HTTP Action in your rule flow since the expression needs the value from the HTTP action… and it comes before your notification (or IF Condition) since the notification or condition needs the result of the Set Variable action.
So you select Set Variable as the action, select the variable you want to store the result in (or create a Text variable first and then select it), then tap the Expressions tab as shown in my screenshot in the source, then fill in the expression based on my example snippet further up in the thread.
Keep in mind that using expressions is a bit of an advanced feature, so you can’t always just copy-paste… in this case, you would need to change the values in the exclusions section of my sample expression from above.
You would use the variable that you used as the target in the Set Variable action since that has the filtered list of device names.
Here’s my attempt at it and I know it’s clearly wrong but hopefully you can tell me where I’m going wrong.
‘Big Mo’ is an openclose sensor that id like to exclude. I have 3 more devices Id like to exclude but trying with one for now. It says invalid variable.
I would like to filter the device list further by the value returned. For example, is battery level between 30-60. Is there a way to set the threshold using isBetween, can I use exclusion based on battery level returned, or do I need to use the filter function?
I’ve tried several variations and keep getting an expression error.
Note that on the first pass filter, we’re just filtering on the batteryLevel and assigning that to filteredItems, so in the second pass filter we need to further filter the filteredItems based on the named exclusions (rather than the original items).
The order shouldn’t matter unless the items being excluded by name are missing their battery value altogether. In that case, the system would have tried to run the filter expression and failed if the batteryLevel on any of the items you wanted to exclude by name were missing their battery level. Swapping the order to filter out those items without a reported battery level would fix the issue as you noted.
We pushed an update intended to better align the Set Variable command with the value type that is stored with the action.
One thing we’ve noticed is that if the variable was originally created as a different type (eg. true/false), and a Set Variable action was created at that time, then the variable was later deleted and recreated, if the Set Variable action wasn’t modified it might still have the original target type of true/false rather than text.
Hi @matt_schuett welcome to the community and thanks for posting. These labs endpoints are specifically designed for the health status and battery features and don’t offer the ability to specify arbitrary capabilities + attributes + values to check for.
If you’re interested in that particular feature, I would recommend casting a vote on it. Community feedback is a key part of how we prioritize what to work on and the number of votes a feature request has on it is one of the factors we consider.
It looks like the SmartThings server is returning errors at an elevated rate compared to before. Copying in a reply from another discussion:
Unfortunately, if SmartThings is having some sort of issue with their API servers that introduced this intermittent type of issue, it’s even more likely to occur with this Labs healthcheck endpoint as it’s aggregating multiple API calls to SmartThings.
It makes an initial request to SmartThings get the list of devices, then individual requests for each device to get their health status before returning that as a single response.
So if any of those requests experience this issue, then the whole response fails.
I was hopeful that it would get resolved on the SmartThings side of things, but if it continues, I’m open to trying some sort of retry/backoff. With this type of aggregated sub-query approach, it can get a bit tricky to decide what to backoff and when. This gets particularly complicated since requests are made in parallel for efficiency.