The Evohome Integration needs a SmartApp for the Honeywell Authorization and scheduled polling tasks.
You could create the base device (with Edge) to which you would send events, but you still need an endpoint app to handle the requests to Evohome.
Using the SmartApp Connector, you could create the complete integration directly. This is the best option because you mentioned Honeywell doesn’t support OAuth 2.0
1 Like
Thank you @nayelyz! Any developer willing to help out making the evohome integration?
1 Like
As I understand it, the edge drivers can use the same custom capability and UI plugin process that Groovy handlers use
Correct, we have tried to improve the experience some by allowing for easier association of all these items in a source directory and “package” them together. Hopefully we’ll have more examples of how to do custom capabilities in the context of edge drivers but here’s the main example we have right now: https://github.com/SmartThingsDevelopers/SampleDrivers/tree/main/custom-capability
2 Likes
I have a couple questions on this example:
- Why is the capability definition have to be in YAML form? The example readme talks about how to get the json output from the CLI, but it doesn’t look like this example uses that. It would be much preferred of course to be able to use CLI output as-is without reformatting for Edge. I know in the alpha we had to provide the capability definition in a Lua table, so this is moving in the right direction: eliminating having to maintain multiple formats of the same file is a good thing!
- What is the purpose of the presentation definition included here? Is it really required?
I’ve looked at that a few times.
Would I be correct in thinking the capabilities and presentations are purely part of the package as a courtesy? Or do they have some function?
Is the deal with namespace.capabilityId basically that the ‘.’ gets in the way?
In the README, and in other bits of documentation, there are references to the ST Lua libraries. I’d been wondering where they were until I found them this morning (I think) as a Release asset in the SmartThingsEdgeDrivers repository. I followed a link in the IDE section of that repository’s README. Did I miss something really obvious? If I hadn’t installed VSCode yesterday I wouldn’t have even read that part and it seems rather subtle.
YAML is a supserset of JSON, so any valid JSON document is also a valid YAML document. Tools like yq can be used to convert between the formats. JSON is great for machine-to-machine communication but in our experience doesn’t make a great human interface as it lacks the ability to include comments, etc.
2 Likes
In part, including them in the package aids in allowing the platform to consistently make the relationship between platform entities and allows for us to avoid a few cumbersome distinct steps of (creating this entitty, get its id, reference its id from this other location). We think that this generally leads to a better development experience and gives us a little bit of additional flexibility to make changes to entity lifecycles in the platform if required.
We’ll be looking at other ways to improve the edge development experience throughout the beta.
Yes, we have decided to make the libs available as an artificact for reference and tooling. These libs will be available are the documented set of libs available for require on target. Having the archive available isn’t required for development but can improve the development experience for tools like vscode or emmy-lua and also includes some of the facilities we use for unit testing.
In addition to tooling, as developers we understand that sometimes for advanced developers, docs sometimes fall short and making the libs source code available is something we hope can aid the developer community in figuring out how all the pieces fit together. Only documented APIs will have any guarantee (past the beta period) of compatibility so use of any APIs beyond those documented is likely to result in problems for drivers down the road (and we don’t believe should ever be required).
1 Like
Ah yes, I see. Now if I am correct I am really just pulling my already constructed custom capability and its presentation out of the API and putting them in the capabilities folder? If so it seems like that is something the package build process should be able to do just as well as me, or probably better than me, in future? Indeed I barely need to know it is going on at all? I think I am OK there.
The ‘custom capabilities’ sample driver is confusing me though. The README mentions the --dth flag in the context of discussion of the capability presentation and says the profile needs to be used instead. That seems to be a bit confused as the --dth flag is only used in the CLI to generate a default device config from a DTH. The sentence doesn’t seem to belong there.
However there IS a device config in the presentation folder that is throwing me. I can match the filename fancy-switch to the profile name in the discovery process (I am probably conflating terminology there as I flit between the ‘Hello World’ and custom capabilities samples), and the vid and presentationId would presumably match the metadata in the profile. However I don’t think there is any more comment about it anywhere as the other sample drivers don’t seem to be involving themselves with it.
My particular confusion is that I can’t see where the device config comes from. I know all about creating device configs / presentations but only in the context of the Groovy DTH where there is a helpful smartthings presentation:device-config:generate --dth <id> to give you a default file to work with. If you omit the --dth you apparently can generate the file based on the device profile. But I don’t seem to have a device profile in the sense the API understands. OK I can build the device config manually, that isn’t a big deal, but I feel like I’ve missed a few paragraphs somewhere.
@orangebucket I agree with you. I believe that we can simplify these instructions and also include a few capability-related commands to actually follow the implementation of the driver and avoid jumping too much from documentation to documentation.
I’ll commend this out with the team at once! 
3 Likes
Thank you.
As I touched on in my first paragraph, I think part of the confusion is caused by the local copies of files in the packages. I fully understand why it is useful for them to be there but I just don’t get why the users should need to put them there themselves. The profile file gives the custom capability IDs and versions and the mnmn and vid are in the metadata in the same file (manufacturerName and presentationId surely?). So hasn’t the CLI got all the information it needs to get the info out of the API itself and create correctly named files in the right place? Why give the punters scope to cock it up?
Is there actually a way to generate a default device config for the Edge drivers? No is a perfectly good answer as device profiles do seem to be a bit of a relic of earlier thinking that are lingering like a bad smell.
By the way, I can’t help feeling there is something odd about sequences of CLI commands that start off with edge:drivers, move on to edge:channels, and then move back to edge:drivers. It makes more sense to introduce the concept of Channels earlier and show them being created first.
1 Like
Yeah, we have discussed some other command or variation of the package command that allows for the primary development path to be less cumbersome. This will probably be some command that performs package, assign, install in one go. (Or at least the first two, the need to do install each time is mostly a workaround for now to force the hub to get the update right away).
One approach we have discussed is having some fixed name channel (e.g. dev) which is automatically created and published/assigned to whenever a package operation is performed. This channel might not be available for sharing but could be used for the development lifecycle. With this, the explicit concept of channels might be something a dev doesn’t need to worry about except when thinking about sharing the work they have done with others (though we have decided it should always underpin the hub/driver relationship).
Anyway, that’s just some of our current thinking if you have feedback on that portion.
Hey! I wrote that guide, but reading through it again, it definitely could have been a bit more clear. You don’t currently need to include any of those files in the package. And those instructions were something I used at the time, but we have since made it a little simpler. If you are OK using the default presentation of a device (i.e. just displaying each capability it supports), you don’t need to create a device config or an explicit profile presentation. As long as you create presentations for the custom capabilities, and then include those capabilities in the profile, the profile will have a default presentation created. I will look into getting some better text written for that example. But if you’d like another example (including a driver in a channel that you could install), I have a driver for a PiHole I wrote here that uses some custom capabilities for reporting some statistics.
I will point out that there are some limitations with regards to custom capability presentations currently. A custom capability will only display in the app with a single command and/or single attribute. These limitations have been reported, but feel free to continue to share feedback if that is limiting for your development.
2 Likes
Sounds sensible to me.
Having revisited the docs (they are blurring together in my mind) I think it is the Hello World example that was irking me. It could just as easily have shown the channel being created and a hub enrolled in it first, and then moved onto the driver stuff, instead of jumping about. However the command that really makes it look odd whatever you do is the edge:channels:assign. It just seems like it ought to be edge:drivers:assign to me.
> $ smartthings edge:channels:assign --help
assign a driver to a channel
USAGE
...
ALIASES
$ smartthings edge:drivers:publish
So edge:channels:assign is actually aliased to edge:drivers:publish so you can use that if you prefer to think about the flow from that perspective.
I am not a serious developer but I’m following this thread with interest. I just want to say how great it is to see this sharing of information and collaboration. It’s very encouraging.
9 Likes
When the preview/alpha of custom capabilities was launched I jumped on board immediately. All I really wanted to do was have a toggle between binary states using separate commands. You know, just like on() and off() except for other binary capabilities. After all who would use a single setter command to do that? Apparently anyone who wants it to work would. Fifteen months on, or however long it is, I refuse to yield.
I’ve actually long since given up expecting the presentation the app is using to match the presentation everything else thinks it should be using. If it does it does. I’m in no way in control.
I don’t even know why I worry about it, it’s not as if I actually use the app for controlling devices anyway and I don’t use Automations if I can avoid them.
1 Like
I think you may have missed my point. The readme file tells you to create a json output of your custom capability, yet in the code example files, there are only yaml files. Regardless if they are interchangeable as far as Edge is concerned, it’s confusing to the reader. The code example doesn’t match the readme file.
A couple other things:
Still not clear if presentation files are optional or not?
In the documentation for the package structure (here), there is no mention of a capabilities (or presentation) folder as an optional part of that. It might be helpful to add that.
Thanks!
A post was split to a new topic: Request - Log Timestamps
Is there an ETA on SmartThings Wi-Fi supporting this, or is support for that product over?