ActionTiles to run Harmony routines?

General Discussion
1

Is there a way to run Harmony routines from ActionTiles? I can run the Harmony routines from the ST app. But they are not listed to add to ActionTiles. I tried to create a virtual switch for each Harmony routine and link that to the correct Harmony routine using Core. But then have to add a virtual switch and a core routine to switch off each Harmony routine. Gets messy very quickly with a lot of virtual switches and core routines. There must be a better way?

2

You should not have to do that at all, mine connect directly to AT. @tgauchat should be able to assist, he is the co-founder.

1 Like
3

Jason you are correct. The Harmony Routines are listed under ‘add things that are missing list’ but not on the ‘things list’ in ST. Your comment made me look again. Thanks buddy.

1 Like
4

  1. Do you mean “ST” (SmartThings) or “AT” (ActionTiles)?

  2. Please reference the ActionTiles Forum on this Topic: Logitech Harmony Activities / ActionTiles Forum / AT Support & Ideas

1 Like
5

I meant the ActionTiles smartapp within ST. There is a section called ‘Select any or all of your things’ and a separate section called 'Add any or all things missing from the first list". I was able to add the Harmony routines to the second list.

1 Like
6

OK… That makes sense…

##Here’s the technical info behind the scenes:

The first list are “Sensors”, the second list are “Actuators”. Many Things are both, so that’s why many Things show up twice:

  • The Device Type Handler for “Harmony Activity” is non-compliant to SmartThings’s specifications: DTH is missing Capability “Sensor” (a Switch is always a Sensor if it reports its State change back to SmartThings – I presume it does?):
  • It is not a critical situation in this case, because ActionTiles only requires that a Thing be present on one list and/or the other (by claiming Capability Sensor and/or Actuator). It does not have to be “correct”.

@juano2310?

7

The way we use capabilities is mostly to inherit the commands associated with it. In this case switch has commands on and off and attribute switch that keeps the state. Actuator can be removed from this implementation without causing any issue.

8

I respectfully, but emphatically disagree!

###Capabilities are also Input Statement *filters!…
“Sensor” and “Actuator” as useful filters due to their nature and purpose as “marker” or “tagging” classifiers…
(ref: http://docs.smartthings.com/en/latest/device-type-developers-guide/overview.html?highlight=sensor%20actuator#actuator-and-sensor)

If I am writing a SmartApp with a single input statement wishing to allow the user to select any or all Things that “can accept Commands”, the tag Capability “Actuator” only serves this purpose if it is used consistently and comprehensively in ALL applicable Device Type Handlers.

Similarly for Sensor: Any Thing that “sets an Attribute”, usually by sensing some environmental condition or external action.

A Switch is both: It has Command switch([on,off]) which is sent by SmartThings to actuate it and it has Attribute switch=(on or off) which is set by the thing and reported via sendEvent.

(A Button, by the way, is just a Sensor; which I’ll leave as an exercise for the reader to determine why).

9

Totally, If all the devices were consistent on the implementation.
The problem is that capabilities have been changing over time. Originally light bulbs were defined as switches but latter it was clear that having a capability light might be useful to identify bulbs and potentially rendering a better UI but it proved harder to replace without breaking current implementations.
In the end, it is a good practice to define the capabilities that fit the device but I think that many devices don’t have capability sensor or actuator in their implementation as of today.
It is true, it can be use as filters but both actuator and sensor are so wide that personally can’t imagine myself using them. That said, filtering was the only reason those were added since those don’t define any attribute nor command.

10

In any platform or language, there are thousands upon thousands of commands and APIs that most of us “can’t imagine using”; until we suddenly come up with a personal use case, or just can’t think of a unique industry or environment where such an API is not only appropriate, it is essential.

In the case of ActionTiles the use of Sensor/Actuator is essential to the fundamental nature of our application.

Therefore, it is essential that all DTH’s follow the published “tagging” specifications in the SmartThings documentation.