Next Developer Call will be on 02/25/15

@April, being new to ST I went back and watched serveral of the past calls prior to the last and felt they were disjointed at times and a lot of dead time or silence. I think it was a great idea to bring you in and and have tou champion the call a little and to track it with a great posted summary. The quality of the last call was 10x better than all the past put together, also a great display of technology with people connected about every possible way… ST and community, great job…

Only thing I would suggest, some people have (ST) or a title next to their name, would be nice if all had something so on the youtube play back it’s easier to know the role of the person talking…

2 Likes

Thanks @jimmay3, that means a lot! I’ll look into the subtitles, or an alternative way to show if some is ST or not!

In the mean time, I can’t wait to see you guys on the 25th! Please do tell us what you’d like to discuss this week. I’m excited to hear your thoughts and share with you my real first hackathon experience!

Could I add
Z-Wave fingerprint using the Manufacturer Specific Command Class
as a topic for a brief discussion?
Currently the list of command classes is being used as a fingerprint but this can and does change over the lifetime of a Z-Wave device. The correct method of fingerprinting is to use the Manufacturer Specific Command Class and the MANUFACTURER_SPECIFIC_GET command which returns three 16-bit values that uniquely identify the
device.
There are a small number of early Z-Wave devices that do not support the manufacturer command class and in that case the list of command classes would help, though not necessarily result in a unique fingerprint. But that number is small and getting smaller every day as those old devices are EOLed.
ALL Z-Wave plus certified devices are REQUIRED to support the Manufacturer Specific Command Class and to have a unique ID for the MFG Specific Get.

4 Likes

Possible Agenda Items (I will edit this in place if I add / remove anything prior to the Meeting):

  • (1) Brief discussion about the the new “FAQ” Category(ies) on the Forum:
    Intended for Community Drafted FAQs on any topic that any member wishes to contribute. The discussion responses on each FAQ Topic can be used for corrections and revision suggestions that the OP is encouraged to edit / roll-up back into the main Topic post. We would appreciate SmartThings engineers to keep an eye out for these FAQs and let us know if there are errors.

    NB: These “Community FAQs” are meant as a supplement to SmartThings official Documentation and Knowledge Base entries. Over time, many “Community FAQ Topics” will probably become obsolete and replaced with official ones.

    Community FAQs can and should include “Known Unresolved Issues, Feature Requests, (& Workarounds) Topics”, and these can be individually deprecated as the issues are fixed. (These might reduce redundant reports of the same problem over and over again.)

  • (2) “New Capabilities” Category: I would like to encourage contributions; (a) new unique Capabilities (even if incremental to existing Caps), and (b) feedback and discussion on open Capability requests.

    Also: I drafted a proposed process for advancing New Capability Requests into the “Final Review” and implementation phases:

  • (3) Services As Things: Two recent New Capability Topics are “Capability Send Message” and “Capability External Logging”. These imply Device Types that are services (like web services) – and certainly (?) can be implemented on the current Platform. They are, however, different from many existing “Things” – they are quite ethereal. Regardless, I think the concept of encapsulating common and useful services as a Capability and SmartDevice Types is a great way to add modularity to the Platform. Instead of repeating code in many SmartApps to write to GroveStreams, for example, there could be a GroveStreams Device Type.

    This will be interesting to explore in practice, however: When does functionality belong in a Device vs. in a SmartApp? Or when does it belong in both? Actually, we have many existing examples of Service Devices that are managed with a Service Manager SmartApp, right? So, hopefully, this concept is really not a big deal.

1 Like

I’d be interested in a discussion on using “sunrise” and “sunset” for event times. The ST status page perpetually contains:

Why is “sunrise” and “sunset” a peak time? My “sunrise” time is different from 99% of the other ST users.

I created a thread for the topic here, but perhaps it would be interesting to hear something on the dev call:

2 Likes

I’d love to see an offset option added to sunrise/sunset, maybe sunrise +/- a value in minutes. Lights turn off at sunrise, but my area needs sunrise+10mins…

1 Like

Can we get an update on the mobile app development? Are there any plans to create a wider API that would allow the creation of a genuine third party SmartThings client application. Maybe, address some of the high level philosophy behind why the platform and smart apps are designed the way they currently are.

1 Like

Couple of things I’m interested in, not sure where they fit.
-How to send raw (non encoded) bytes via HubAction
-expanded and complete documentation for dynamic page methods, including href as well as inclusion of several parameters that exist and aren’t documented, there’s at least two I know of, content: and refreshTimeout.
-expanded documentation on childDevice methods.

2 Likes

More of a quick note than a full discussion point, but why do the GE Link device types respond that they need two arguments for setLevel when they only respond to setLevel with one argument.

For example:

def device = myGELink //display the details for a GE Link device
[
        id: device.id,
        label: device.displayName,
        commands: device.supportedCommands?.collect {[
                name: it.name,
                arguments: it.arguments
        ]},
        type: [
                name: device.typeName,
                author: device.typeAuthor
        ]
]

Would result in something like:

"id" : "598a9535-1b8b-4fa0-a940-7a412212d094",
"label" : "GE Link",
"commands" : [{
        "name" : "on",
        "arguments" : []
    }, {
        "name" : "off",
        "arguments" : []
    }, {
        "name" : "configure",
        "arguments" : []
    }, {
        "name" : "setLevel",
        "arguments" : [{
                "enumType" : "physicalgraph.device.DataType",
                "name" : "NUMBER"
            }, {
                "enumType" : "physicalgraph.device.DataType",
                "name" : "NUMBER"
            }
        ]
    }, {
        "name" : "refresh",
        "arguments" : []
    }
],
"type" : {
    "name" : "GE Link Bulb",
    "author" : "SmartThings"
}

Ninja Edit: there are several other device types that will at least take the second argument, but not do anything with it (eg. dim normally). But the GE Link ‘advertises’ that it wants two arguments but will fail to process the command if you send it anything other than one NUMBER argument.

The two parameter setlevel command in the device isn’t implemented or even stubbed out.

capability.switchLevel is spec’d out to allow two numbers but only uses the first.

I can only speculate that the second number was intended to be used as the ramp speed that some dimmers allow.

However, it doesn’t work. Guess it is best to ignore it until further clarification.

Exactly! :smile: Why does the arguments property of the GE Link setLevel Command indicate that it wants two arguments if it doesn’t even implement a method that takes two arguments. Is it truly just the ‘switchLevel’ capability which has defined the second argument as required? If so, why is that not enforced in the implementation of the setLevel command within the device type. (Sorry, seriously not trying to invite another interface comparison discussion)

I’m pretty sure I’ve seen community versions of the GE Link device type that basically map the two argument command to a single argument comand eg. def setLevel(arg1, arg1){ setLevel(arg1) }. I think this mapping and acceptance of a spurious second argument perhaps could be even more confusing though. If the device is intended to only accept one argument, then it should really just have one argument in command.arguments

I’ve seen in other threads where the second parameter is used as the ‘duration to dim over’ for certain switchLevel devices although I don’t recall which ones off the top of my head.

It isn’t just the GE Link, its the capabilities spec in the documentation.

Think of it as an optional overload not as a required field and all is fine in the universe.

I have Remotec dimmers that, indeed, use the second argument to affect the ramp up or down duration (in seconds, I think) of the current setLevel request.

Actually, I’ve been wishing to modify the SmartDevice Type to take a user Preference configuration value that would be used as the default ramp speed whenever a value isn’t specified. That way all the SmartApps that don’t supply the second argument would still operate with my configuration preference. Sure – it may be defined and storable “in the physical device” as a Z-Wave configuration element, but using SmartThings’s Preferences makes it manufacturer independent, as long as that parameter is supported at the execution time of setting the dimmer level.

The problem is I use the reflection-like capabilities of the platform to allow my users to control their Things through my Android app, SharpTools. Instead of manually coding in overrides for various oddities like this, I was hoping to better understand why the device type doesn’t just indicate that it wants one argument when that is all it accepts.

Note that the GE Links will simply fail to dim if two arguments are sent. At the very least, the official GE Link device type should stub out a two argument setLevel command that maps to a one argument command… especially since the command.arguments property currently advertises that it accepts two parameters. And I believe it would be even more reflective of the actual device command capabilities if it command.arguments only responded with a single property in this case, but I understand that may conflict with the capability.switchLevel definition.

For reference, see below for a few screenshots of the ‘A Thing’ configuration screen in my app. Users use this screen to setup what they want the Widgets on their homescreen or Tasker action to do. As you’ll see in the second screenshot, I have provided an interface to allow users to override these parameters and remove the spurious second parameter, but this obviously isn’t ideal as many users don’t know to do this.

I agree that you describe the desirable and proper behavior.

The Capability “Switch Level” is an interface definition contract, and any and all SmartDevice Types that offer this Capability must offer all the Attributes and all the Commands (including all method signature variations), with either “meaningful” results and/or “null-safe” results (i.e., if a device really can’t dim, then it should stay lit for all Levels above 0; and if a device doesn’t have a selectable ramp up / down speed, then it should just do the default of immediate or manufacturer’s hard-coded speed).

I will likely not be able to join the call tonight, or perhaps may arrive late.

You are welcome to proceed with or without my suggested Agenda items (earlier post).

Thank-you… Miss you all.

1 Like

Thank you all for joining me this week. Remember, as I invite you for the next one, feel free to integrate your questions on there. The earlier the better : That way I can call in the right engineers for each one, and ensure they’re there to answer your questions + your feedback.

I’ll let you know, I’ve been publicizing this internally, making more of our team join us to gather the feedback that you have for them…in addition to what you already provide in the forums here.

Thanks again for all your participation, dedication, and dealing with my constant obsession with children and animals.

1 Like