Labs: SmartThings Health and Battery Reports

[Terri]

I’m playing with the Battery check lab. Am I able to filter items out in the textSummary context or only the items context?

If I need to use the item context, can I then format it to read more like the textSummary format with only the device name and battery %?

[josh]

@josh

items = $context.response.data.items
exclusions = ["Motion Elliot"]
filteredItems = filter(items, not(contains(exclusions, item.name)))
join(map(filteredItems, item.name), ", ")

@Terri

If I need to use the item context, can I then format it to read more like the textSummary format with only the device name and battery %?

Yes, in the example above, the last line is doing two things:

1. The map() is mapping the detailed item to only display the item.name
2. It’s joining all of the filtered items (which have been remapped) into a string with a comma and a space between them

So you could modify the map() part to combine whatever parts of the item together as you see fit.

Here’s the same thing but with those last two steps split out and the map() step concatenates a string together as you alluded to:

items = $context.response.data.items
exclusions = ["Motion Elliot"]
filteredItems = filter(items, not(contains(exclusions, item.name)))
formattedItems = map(filteredItems, concat(item.name, " (", toFixed(isEmpty(item.batteryLevel) ? 0 : item.batteryLevel), "%)"))
join(formattedItems, ", ")

I added some fallback checks to the example as I had some battery levels that were reporting as ‘null’ which was throwing things off.

[Terri]

I finally had time to come back and play with this. Thank you for the help Josh.
I do have another question.

I am using this expression

items = $context.response.data.items
exclusions = ["SmartTag Keys","Hub 2 Master","Hub 2 Living Room"]
filteredItems = filter(items, not(contains(exclusions, item.name)))
formattedItems = map(filteredItems, concat(item.name, "-", toFixed(isEmpty(item.batteryLevel) ? 0 : item.batteryLevel), "%"))
join(formattedItems, "\r\n")

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.

[josh]

I would supply the upper threshold as part of the URL, then you could filter the list multiple times as needed.

Something like the following:

items = $context.response.data.items
exclusions = ["SmartTag Keys","Hub 2 Master","Hub 2 Living Room"]
filteredItems = filter(items, item.batteryLevel > 30)
filteredItems = filter(filteredItems, not(contains(exclusions, item.name)))
formattedItems = map(filteredItems, concat(item.name, "-", toFixed(isEmpty(item.batteryLevel) ? 0 : item.batteryLevel), "%"))
join(formattedItems, "\r\n")

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).

@josh

Battery Check

The Battery Check endpoint returns a list of devices which are below the provided threshold (30% by default).

https://lab.sharptools.dev/smartthings/batterycheck?token=XXX&threshold=20

As indicated in the example above, you can provide an optional threshold value to adjust the upper limit for battery values included in the report.

Response Properties:

• textSummary: a human readable list of device names; can be used directly in notifications
• items: an array of objects which each include a deviceId, name, and batteryLevel property

The format of the response is very similar to the healthcheck endpoint with the addition of the battery level within the human readable textSummary property and the inclusion of a batteryLevel property within each object in items.

[Terri]

Using what the expression you suggested results in an expression error.
I had to reverse the filteredItems lines.

items = $context.response.data.items
exclusions = ["SmartTag Keys","Hub 2 Master","Hub 2 Living Room"]
filteredItems = filter(items, not(contains(exclusions, item.name)))
filteredItems = filter(filteredItems, item.batteryLevel > 55)
formattedItems = map(filteredItems, concat(item.name, "-", toFixed(isEmpty(item.batteryLevel) ? 0 : item.batteryLevel), "%"))
join(formattedItems, "\r\n")

[josh]

Nice! Thanks for the update.

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.

[John_Johnston]

Hi mate. My pushover notifications have started to just say this now. I haven’t changed anything within this rule. Is this a bug or something?

Here is my set up

Thanks

[josh]

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.

@josh

Can you try the following steps to make sure the Set Variable action has the appropriate target value type:

1. Open the rule for editing and edit the impacted Set Variable block
2. Switch the ‘Source’ to Manual Input and then back to Expression*
3. Save the Set Variable block and then Save your rule

You should be able to run your rule again and it will pick up the proper inferred value type for the expression. Video demonstration attached.

*The expression should be retained when switching the source to Manual and immediately switching it back to Expression, but you can always copy the expression to your clipboard as a precaution.

[John_Johnston]

That did it mate, thank you once again.

[matt_schuett]

any way to add another endpoint for status == open.

this would help the scenario posted here

which is essentially check all my contact sensors and let me know what is open

[josh]

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.

@matt_schuett

this would help the scenario posted here

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.

[John_Johnston]

Sorry to bump this but sometimes my pushover is giving me this error when it checks if something is offline or not. Other times it will work.

[John_Johnston]

Bump.

Hoping someone has a fix for this?

[josh]

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.