Next Developer Call will be on 02/25/15

General Discussion Groups & Events
1

Next Developer Call will be on 2/11/15
Please let us know what you want to go over on the next call below!

Every other Wednesday for 1 hour
8pm EST / 7pm CST / 5pm PST

To join the Meeting:
https://bluejeans.com/574546266

To join via Phone:

  1. Dial:
    +1 408 740 7256
    +1 888 240 2560 (US or Canada only)
    (see all numbers - http://bluejeans.com/numbers)
  2. Enter Conference ID: 574546266

Developer Discussion Summary for 2/11/15 :

Meeting starts at 12:00 Mark

Brian hates internet explorer, chrome 64 works. Blue jeans now work with Chrome. :slight_smile:

-Review on updates for iOS/Mobile
-Hackster.io/smartthings integration where you can just put a link from the community. Published projects on community, just pasted your URL.
-We are hiring
-Mager updates :
Accelerator program, talked to a bunch of companies. One was a smart lock: Latch. excited to what they have built.
SmartThings Meet up NYC.
smartapps submissions : a few moved to QA and others have moved to code review,
4 apps published this week, expected 5 next week.
Jim and Mager working on developers portal.
U o M 200 students building cool stuff.
Aurdino docks to actual developers site
TreeHacks : 500 students
Events schedule is on developers site now
If there are events you’re interested in us going, let us know.

-Gilbert update :
Delivering CES promises that was demoed, over the next weeks and months
Working on video service.
Working with a lot of partners with better integrations, looking to improve reliability.
Tyler Lange’s Certification program : device certification, going through community beta test for better smooth sailing out in the wild.

-Jim Updates:
FIRST TIME GOING TO A HACKATHON!

  • Matt Updates :
    Platform release notes out this week, like previous ones. Focusing primarily stability and performance issues.

Community QA:
Follow up on last week’s call, working on a device health initiative. Core team on device health, how to surface that. Health dashboard on devices.

Follow up: How can we expand to new capabilities. Process of the capabilities -
Action: Ben created a sub category.

Hub V2 App overhaul : Gilbert confirms. Ready when its ready.

Samsung app going to be released: A team from Samsung that will be making Tizen ones. will be working toward more

Plans beef up documentation on the short term? Jim to work on documentation that we can create.
comment on the repository, we can see those there, in case something is out to date.

Priorities on UPnP.

Device types running locally.

we are building an ambassadors program . we want to have 10 ambassadors at end of the year.
shifting away from students hackathons : really engage professional developers for this year event’s focus.

we talked about marketplace, and will make a more public announcement soon regarding stance.

Documentation and NDA on early beta access.

Talk about : Native devices and smartapps having push notification

Bob will join next call to talk about those things Github integration

Matt will look at IDE logout issues that Mike and others are experiencing.

Working towards a better Github integration : Once you submit, then you submit changes , those changes will connect. If you change someone else, it will branch and reflect that on the IDE. A more full GitHub integration will happen

2 Likes
2

@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
3

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!

5

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
6

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
7

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
8

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
9

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
10

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
11

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.

12

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

13

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.

14

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.

15

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.

16

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.

17

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.

Pasted image1080×1920 72.1 KB
Pasted image1080×1920 88.4 KB

18

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).

19

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