Continuing the discussion from Capability.urgentAlert:
I was thinking of this idea before reading this, but it didn’t seem to be addressed much in the previous thread. I’m going with the recommended “spinoff”.
With notification services being used (such as Pushbullet), it might be useful to have a sendMessage capability that utilizes a push(message) command. Then smart apps could be written to include all notification service devices rather than having to focus on one service.
I’m so glad you picked it up! I wrote about this same thing a year ago.
I put this on the Developer’s Call for Wed Feb 25th.
Agenda Item: Can any service be a Thing?
Eg. This one, and also Capability External Logger.
The static parameters are in the SmartDevice Type for each service + Preference at instance creation for individual id, key, password, etc.
This seems to be a reasonable way to abstract and modularize various types of useful services, read, write, or both.
Capability Weather Report, for example could be another “Service Thing”… But let’s see if “Send Message” can be hashed out as a Proof of Concept first.
The Command(s) take the message + any optional arguments like address (if not the instance default), notification sound, priority,… Not much else needed?
It works like any other Cloud-to-Cloud device (like Nest, I think is a comparable example).
This seems like a reasonable and promising way to abstract and modularize useful common service types for use in many SmartApps instead of duplicating code and without requiring new global libraries / methods.
Capability Weather Report might be another, but let’s hash out Send Message first as a Proof of Concept.
It’s not how you would typically do it, but you might be able to fit it into the model if there were a virtual fictional device called VirtualMessageFactory. Then you give it capabilities you can send/receive in the device type. The device handler would have a lot of work to do, though.
That said, it would still have to be set up for specific web services so you’d get all the parameters set right.
It still worries me. i don’t like shapeshifters in code that will be used by a whole community. Implying a device for what is really a method seems dangerous to future coders, regardless of their experience level.
I understand the desire to avoid the details of web service management and make the coding as easy as possible, but the details have to be in there someplace.
Thanks for your response, but I don’t understand this statement at all.
A “Send Message” Capability describes an interface to a service to send messages. It is not a single method. It is an instance of an Object with various Attributes and Methods Commands.
In SmartThings we can’t create our own Classes or Objects, except for SmartDevice Types, Device Instances, and SmartApps, and a few others.
We “imply a device” for, well, everything. A Philips Hue Bridge is the physical interface used to find an instantiate Device Instances for light bulbs, but the light bulbs are just objects with Switch, Switch Level, and Color Attributes and Commands (methods).
Anyhow – At the moment, this concept seems perfectly clear and fine to me, so I think I’ll need to hear some other’s feedback to figure out what the OP and myself may be “missing”. That’s why it’s on the dev call agenda for today.