Calling All Developers - An open proposal for cross application triggering

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…

I found the sendLocationEvent to be pretty well documented. I don’t regard this as a non-documented API call. I agree with the point that no app should indirectly gain access to devices it was not authorized to use, though we are talking about the target app as the middle man, so access to the underlying device is somewhat limited. Also, a user has control over which apps he installs, though for most that doesn’t mean it prevents any undesired access. I will look into a way to limit access on the receiving side of the sendLocationEvent by means of having an allowed app list. But again, sendLocationEvent was intended for such usage, this is not a hack.

1 Like

@tgauchat I am at a cross-roads between working on making required modifications to CoRE (split into parent-child is the sole request so far) and working on webCoRE, a much lighter code base version of CoRE that offloads the whole UI to html5+bootstrap+angularJS. While I am more excited about webCoRE (mostly because I can break all the boundaries that the ST app artificially imposes), I am ready to get to work on CoRE to get it published. I am, like I said, at a crossroads and am not sure which road I should follow first.

The webCoRE UI is much much faster to work with (no web requests during building the piston!) and also allows export/import, backup/restore, and most importantly… SHARE. Imagine this: all device handlers are removed, all phone numbers removed, all contacts removed, just the structure saved online and easily imported as a template by anyone using a six-character code… (myjson.com).

There is no need for integration with CoRE per se. CoRE exposes the list of pistons via an event any app can subscribe to. CoRE listens for events that any app can send. The only integration per se is if the foreign app needs CoRE to send custom events to it (CoRE executing code in the foreign app).

I am open and very optimistic, still. I found many of the ST employees to offer great unconditional support. I am hopeful CoRE (or webCoRE) will eventually be published. For now, the cat is in my yard.

2 Likes

You should work on the version / architecture that is most likely to be approved for publication. That should be your #1 priority for the maximum benefit to all SmartThings Customers.

1 Like

I will ask around, but it’s most likely that ST needs to see such an app before they can express their opinion. We’re talking about an app that has no configuration UI inside of ST. Is that allowed? Nobody knows because no other app does that. Yet. The closest is probably SmartTiles, but ST does not follow logic created in the ST UI.

There certainly is precedent… @obycode’s SmartRules and the (approved) ActionTiles.

But you observe correctly that SmartThings does not “pre-approve” apps in concept. Only fully coded completed SmartApps. So you risk rejection only after doing all the effort.

1 Like