Calling All Developers - An open proposal for cross application triggering

Hi All,

I’ve been thinking about cross application integration now for a few weeks, partially as I am developing my own app, I know we can use dummy switches (but that’s painful) and I know that there are now a couple of applications specifically integrated or planning on integrating with CoRE.

However I have a proposal, that potentially makes bespoke integration needless and would then hopefully mean that a developer could integrate with any other capable application easily, however this would require key developers and the community as a whole to contribute, discuss and come to an agreement…

Do you think that this could work?
.

My proposal is:

  • Harness sendLocationEvent in the same way CoRE already is with AskAlexa
  • but make this a generic community event
  • Each triggering app will listen for events on this LocationEvent for new events to trigger
  • All apps using this community interface will have a small method, which is generic across all apps, to ensure consistent experience across all apps.

Starting point:

So rather than coming to the community with an idea, I have written some proposed code.

This code is a working idea, it may not be the best way to achieve this as I code for a hobby not a job, it may not meet everyone’s requirements, it may be completely deleted and re-written by someone else, and any feedback / changes / pull requests or even just saying it’s a bad idea are welcome… but it is a start! :smile:

What it does:

  • It is a handler for the LocationEvent name:“appLink”
  • It listens for (add) / (del) events from other apps
  • It has in built handling to generate the (list) of all available apps and events to trigger
  • It can send a LocationEvent directly to the app that should receive it, with an event ID to trigger
  • It could if required also act as a response handler for success or failure, but I have not coded this as I didn’t want to spend a lot of time potentially writing some code that may not even be accepted by the community, and there may not be demand for it.

Data Structure:

  • Data is held in a nested map [AppName: [TriggerID : TriggerDescription]]
  • The AppName and TriggerID combined are the unique globally
  • The TriggerID is unique within the target app
  • The ID can be anything, but I would suggest if triggering child apps that you use the app ID, but could equally be any string.
  • The list function returns the “[AppName] Trigger Description” producing something like the below, and is very simply called by appLinkHandler(value: “list”)

Code:

Essentially the core handler is the below 10 lines of code (depending on how creative you get with the return button)

def appLinkHandler(evt){
    if(!state.appLink) state.appLink = [:]
    switch(evt.value) { //[appLink V0.0.1 2016-11-23]
   		case "add":	state.appLink << evt.jsonData;	break;
        case "del":	state.appLink.remove(evt.jsonData.app);	break;             
        case "list":	def list = [:];	state.appLink.each {key, value -> value.each { skey, svalue -> list << ["${key}:${skey}" : "[${key}] ${svalue}"]}};
        	return list.sort { a, b -> a.value.toLowerCase() <=> b.value.toLowerCase() };	break;
        case "send":	sendLocationEvent(name: "${evt.data.split(":")[0]}", value: evt.data.split(":")[1] , isStateChange: true, descriptionText: "appLink Action")
    }
    state.appLink.remove("$app.name") // removes this app from list - optional/editable
}

Sand Pit Source:

I have a very rough outline of the code, with many comments throughout, showing how it can be used! The app itself from the front end is uninspiring as it is just a sand pit to play, I’ve just left code commented out which you can un-comment to activate when the app is run, and as it’s a demo it has dummy data just to show you what it’s doing (you will need to save the app exit and re-inter to populate the list for the first run)

Code can be integrated via GitHub in to ST

https://github.com/jebbett/appLink

https://github.com/jebbett/appLink/blob/master/smartapps/jebbett/applink.src/applink.groovy

3 Likes

Tagging the developers I think may be interested in working on this…

Feel free to add anyone else I have missed (I’m sure there must be many more)!

@ady624 @MichaelS @bamarayne @SBDOBRESCU @tgauchat

3 Likes

Great idea, but I have one major (?) concern to think about…

Location Events are inherently insecure. Any installed SmartApp, even if it has no authorized “Things”, can trigger and subscribe to Location Events.

The alternative I have proposed a few times would leverage the “device security model” of SmartThings: Use a custom virtual Device Type Handler and one or more instances of it (virtual Event Queue Things) instead of Location.

Except for the hassle of installing the DTH code (which hopefully SmartThings would consider publishing on the platform?), this would put the Customer in full control of which SmartApps can communicate with which other SmartApps.

i.e., each set of SmartApps allowed to interact would use their own fully private instance of the Virtual Event Queue Thing. The Customer would have to “Add” these virtual Thing instance(s) like any other of their Thing(s) they authorize when using the Preference pages of the SmartApps. Of course, darnit, this means this new DTH would also have to claim a Capability that made some sense – again, hopefully SmartThings would add a new Capability for this. Oh… that’s hopeless, I know. :confounded:


Is this unnecessary extra complexity? I dunno… it’s subject to discussion. But I think we do need to seriously consider the security implications of our SmartApps utilizing Location.Event for critical functions, since any arbitrary SmartApp can write messages Location.Event!

2 Likes

It’s definitely something to consider if using for critical applications, but the user would still need to subscribe to the event, a simple in app switch could define if it reacts and publishes the ability…

I still struggle to think of the real life instance where this would actually be at risk of happening though? I assume that this event would need to trigger from some other app on the hub, and the user would have needed to have installed the app in the first place?

In my specific application, I would happily sacrifice the rare* possibility of this happening in favor of not having to install any more virtual devices on my hub :slight_smile: although I would sooner a better native solution within ST, I expect they are too busy trying to make the apps and features they already have first :scream:

It’s not an ideal solution agreed, but I think the risk / reward is acceptable for most use cases…

2 Likes

Correct… But from history, we know that third-party security researchers are very sensitive to perceived vulnerabilities and SmartThings is very reactionary in response.

(Ummmm… I should look up and paste a link here for reader’s convenience.)

SmartThings’s position is that every SmartApp has at least secondary level of access granularity; i.e., even an “explicitly installed” SmartApp can only access Things that the customer authorizes in Preferences (and a SmartApp must have no way to access Things that are not so authorized).

In fact, security researchers expect SmartThings to enforce the next level of granularity… i.e., explicitly limit the SmartApp to the Capability filter specified in the Preferences input. The example the researchers used was a SmartApp with an input asking for devices of Capability Lock, but not Lock Codes… can still use the Lock Code setting Commands of the authorized devices!


In other words, SmartThings can (and perhaps should) be very sensitive to any paradigm that spreads further non-granular access. Use of the Location object is quite concerning to me.

More importantly, though… Will the use of this technique cause a submitted SmartApp to be less likely to be approved for Marketplace publication or outright rejected?

1 Like

While I applaud the effort to create the glue to bind some of these apps together, I am not sure this is the best way to do it. Outside of Terry’s concern, if an app has to be re-written to utilize it, it might as well write directly to the app it wants to interface with. I defined my own structure for the message queue, and another structure for Ask Alexa and CoRE to integrate. Having a generic structure limits how the authors want to implement this.

Again, a good idea, but I think this is the responsibility of the app owner to implement this.

I appreciate the idea! Exactly what I did with the interfacing of other apps to Ask Alexa.

1 Like

I would be very cautious committing to a non-official API or pattern. I got burned too many times for thinking outside the box and using unconventional methods.

3 Likes

My point here is though that, you have had to integrate with CoRE, and then if someone else wants to integrate you would potentially have to write another interface structure and CoRE would need to do the same, and then other apps would need to also work with you to integrate there also… as well as integration with each other… (obviously each integrations effort would differ depending on direction of integration)

The idea behind this is that you could integrate with any other app potentially with no additional development for you and no additional development for developers. If I created an app today I would need to write separate code to integrate with CoRE and AskAlexa and any other App that comes along in the future, but would also need you to update your code and code in core potentially, or at least I’d need to fork the code, but I don’t really want to be playing with someone else’s code to make things work .

I’m not saying my proposed code is the answer, but the current method you are using with CoRE I think it an easy method to setup from an end user perspective and good to maintain, especially if you have a lot of activities you want to trigger app to app, but it’s just restrictive to the specifically developed apps.

What my suggestion is, is that the people with the experience of this, work together to develop a universal standard, and ideally this would benefit from the experience that the CoRE team and yourself have gained in developing your existing solution. If things have been done in different ways in each of the two system, then work out which is the best and most flexible to use as an open standard, rather than everybody doing their own thing, as we have enough of that in the home automation industry anyway :frowning:

Personally I’m happy to integrate apps I’m developing with other app developers (it would probably be less work than agreeing a standard), but I could see instances where there is significantly less benefit to them, just thinking that a community agreed and documented standard would save a lot of work in the future as more apps become available…

Like I said though, if key devs like yourself aren’t on board then the system falls apart, but also if it’s just a bad idea then there isn’t a lot of point progressing it, worth asking the question at least though i guess… :disappointed:

1 Like

Yeah I guess a good point, my thought was at least trying to standardize how it’s being used between apps, but I get your point :disappointed:

Jake,

I completely get the process and I should not have been so quick to shut it down…it was not my intention to dismiss your thoughts as this IS a great idea. But as you can see from my fellow developers, there is a bit more involved than just publishing a standard…there is the security involved, along with it never officially being supported by SmartThings. And, you have to admit there is a LOT of upfront work for the developers…

For example, If you wrote a stand alone app today (and you implemented your “glue” app), EVERY app out there that you want to integrate with would have to re-write their code not only support your “glue” integration, but the internal workings of WHAT it was supposed to do with the output of your main app. You then get into the same situation as we are in today without your “glue” app…we have a common ‘area’ (The sendEventLocation) that can be used already to move data between apps…And that apps that WANT to talk together already do (my app and CoRE, Device Manager, Nest Manager, etc).

Again, I REALLY REALLY appreciate the effort and thought that was put into this…This is what the community is all about!

I hope this wasn’t too discouraging :frowning:

1 Like

It is DEFINITELY not a bad idea!

The problem isn’t with the idea … the problem is that SmartThings shows very little interest in developer feedback to improve their architecture. For example, the entire “Capability” paradigm is very good, but has gaping holes and inconsistencies. I raised that specific area of concern 1.5 years ago, and it died on the vine About the Capability Types Suggestions category

Inter-SmartApp communication is an integral part of the SmartThings architecture and is meant to be done via Devices.

Are there legitimate needs to expand this functionality? Sure … but … take a number?

2 Likes

No problem I do get what you are saying, but I do think there is some misunderstanding of my suggestion :slight_smile:, my suggestion is not creation of a glue app, and not even an app at all.

The whole point is that there isn’t something sitting in the middle (the app posted is just a skeleton to demonstrate the ability)

So in my initial post there was a an example block of code, and all that codes purpose is, is to capture other apps publishing their availability and to bounce back to anyone of the other apps to say, that the published item has been triggered.

Those 10 lines of code, pretty much do all of the interface work, as in right now without any further development (collecting available activities, maintaining them in case of update/add/remove, and send an execute request), and could in theory exist in every app that wanted to publish their availability. My thought process behind it is that this block of code is kept simple and standard (but community designed and agreed) and any app that wants to be able to trigger another app just needs to paste in this block of code, and only 3 more lines (the subscription, the list and the line to execute:

subscribe(location, “appLink”, appLinkHandler)

input “appList”, “enum”, title: “Trigger This App”, required: false, submitOnChange: true, options: appLinkHandler(value: “list”)

appLinkHandler(value: “send”, data: “$appList”)

So if you added those 3 lines of code (copy and paste) plus the event handler block… this could then trigger events to any other applications that have the same code block, but their own handler, which would listen for the appName and unique ID…

Sorry if any of that was not clear from the original post, but thought I should explain better… as I don’t want anyone thinking I’m developing and app to translate between other apps, my idea was to have a small set of code that exists in each app as a common language, not to translate…

EDIT: Sorry for another long post!

I see…I guess I did misunderstand. However, it still necessitates the apps out there to re-write their integration that already exists and any new apps to plan for this integration along with a framework of WHAT an external app can and can’t do…And that brings up Alex and Terry’s comment about security…ST would never allow their apps to do this, and any community app that wants to be published couldn’t use this method.

I think this is part of the point though :slight_smile: If SmartThings aren’t willing to develop something that fixes the problem and has a defined and documented standard for it, and we have a couple of apps now talking to each other using location events using different methods, as the community grows more people will do the same in their own way, creating a variance in how it is done between apps and making everything progressively more complicated and distributed… Realistically this is going to happen, I’m just proposing rather than waiting for ST to develop something new that we control how we are doing it as a community as that’s the only thing we can control…

I do take your sentiment on board though, please don’t think I’m ignoring your point :slight_smile:

1 Like

I love your optimism… and maybe there’s more hope than I give the Community credit for.

However, my lack of optimism comes not only from SmartThings’s lack of interest in the “New Capabilities” Category (for example), but also the *entire Community’s" abandonment and neglect of it.

Perhaps your initiative will gain a stronger foothold, or perhaps Community unity has improved over the past year.

1 Like

Yes agreed, but could exist along side any existing integration if required, and would be just the 13 lines of code and perhaps a loop, for multiple select… * Just to be clear this would just be for a trigger, like telling x piston to run.

So this was part if what my intention was for defining what the use cases would be, but essentially as it stands the triggering app would have no idea what the functionality is, it would just trigger and ID, the target app would see the trigger and act on it (like a momentary button press). So if you asked Alexa to trigger Macro 1, then under Macro 1 you would select an item from the drop down… all the Alexa app would be doing is saying to execute the item in the drop down… If you start to look at additional capabilities and move any brains away from the target app, then you open this up to a whole world of complexity which would be un-managable without an intermediary app, and even then difficult.

True but this method is already being used in both CoRE and AskAlexa, both probably in the top 3 active apps of the moment (I couldn’t leave Smart Tiles off the list :blush: )

Anyway, I do also take on your feedback, I do just wish there was an easier way to integrate between apps, without putting virtual devices in the middle :frowning:

Yeah…I get it…Unfortunately I am too far down the path and have already established and documented my message queue standard, so I would probably not participate in this unless there was a ground swell of people that wanted this feature.

1 Like

I’m living the pipe dream :smiley:

I was just thinking/hoping with the success of CoRE that perhaps that the community would collaborate on developing a standard that would enable every app to integrate with CoRE and fire a piston without bespoke integration, adding more code to the already huge pages of code.

I expect @ady624 is my last hope in this battle, but I fear that this one is already lost :wink:

1 Like

The real success of CoRE (and the dream should be…) to have it officially approved and published as a Marketplace SmartApp.

That is more likely if the Community doesn’t push boundaries until after initial publication, for incremental revisions… Maybe.

Odds at publication as is are pretty low, I think… Sadly.

Unfortunately I think that’s the case for pretty much any app developed by the community regardless of it’s integrity…

To be honest, I don’t use any officially published apps anyway, unless Smart Tiles was published and I wasn’t aware?

I have pretty much my entire home automation and entertainment running though a custom app I wrote and have put a lot of hours in to, and one of the biggest reasons for this is that any official apps were far too limited and didn’t meet my requirement because of this, previous to that it was rule machine based, which was still a little hacky to get the things working the way I wanted, with switches holding states etc…

Eventually I will publish it to the community as it is really easy to setup, hopefully even for a beginner and the key is that it doesn’t rely on dummy switches and those hacky type things and avoids using those things in ST that regularly fail, but still has the ability to externally integrate should you want to. As soon as I complete the “security” element of it then I’ll probably post it as an alpha or something…