Next Developer Call will be on 2/11/15

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:

To join via Phone:

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

Here was last week’s Developer Discussion 01/28/2015

Be notified when developer calls occur via calendar invite:

or download our Developer’s events calendar here:
[Download Now][1]

Discussion Overview :
Discussed new release notes for hub firmware
Performance improvements from the IDE
Resolving bugs around deleting users and prevented Hues app from being uninstalled, and service manager changes
Priority on SmartApps submissions, now up to Jan. 15
Building our ambassador program projects that you built, eventually import from community site too.
Delivering what we showcased at CES, demo : next generation hardware, platform, releasing our next gen hub: local processing, smart apps firing locally
Releasing new sensors : micro-motion, micro-multi, presence tag: New housing
Video service, along with premium services : Live-streaming, recording/motion detection/ clip base / 24-7 monitoring
Incident Management
Working on resolving issues with TCP
Discussion about expanding capabilities
Modes and Security issues
Upcoming changes about Device Lab, beta program
T-Shirt contest- Forum post until Feb 9th, 2015
Discussion critical alert mechanism as device type
Model specific device types showing relevant capabilities
Groovy and Grails isn’t going away - however potential languages support
Conversation about needs of dynamic tiles

1 Like

(OMG… So yours-truly is the featured keyframe from the last call!? Sure glad I cleared the clutter off of the top of my printer / scanner before the meeting! Next time perhaps I’ll aim the camera at one of the beagles…). :blush: :dog:

You could follow in the footsteps of @wackware. He’s often connected to the call, but always has the camera pointed at something else.

1 Like

As part of the agenda, can a few minutes be reserved for ST to recap some of the issues left open during the last dev call? There were a few different things that were left with “thats a good idea…” or something similar - it would be nice to know if there’s any news on those things. (Examples: expanding capabilities, a mechanism for device types to inform users of critical alerts, etc.)

Thank you


agenda += discussion on the planned github integration. Not as a nag to get it done (even if it’s implied), but as a discussion to understand what ST has planned.

From the developer point of view, it’d be nice to be able to commit changes made in the IDE to github. It’d ALSO be nice to have changes in the github branch instantly show up in the IDE (or perhaps in reaction to a button press.)

As well, from a non-developer point of view, will it be set up so that a user could just type in a github link to instantly have access to a new device type or smartapp? If so, if the code pointed to by the link changes, will the user’s device type or smartapp also change with it? (a simple way to do upgrades.)


Hi All! just pinning this for visibility. Remember, tomorrow is our next Developer’s call! :slight_smile: Join us and share with us your experience. Let us know if you have a topic you’d like to talk about here for the agenda tomorrow, like the posters above.

Invite your fellow ST’ers to join the call!

1 Like

Is there an App overhaul on the horizon?

When is the Samsung TV app going to be released?

1 Like

I would like to revisit the topic of local SmartApps on Hub v2. In particular, I’m interested in the plans for Endpoint SmartApps (including local authorization) as it was one of the unanswered items from a previous call.

I also have a sneaking suspicion licensing will be a topic of interest for many community devs. :no_mouth:


I’d like to understand the ST implementation of UPnP Eventing and how NOTIFYs are routed to Device Types.

1 Like

There has been a lot of back and forth on the boards about this issue. I would like to hear the thoughts of those within SmartThings on the questions that have been raised on the forums. Particularly, any rules of the road that ST would like developers to adhere to when advertising services or hardware. I would also like to hear the ST vision for community building plans and developer evangelism.

I would also like to revisit the idea of having separate video conference maybe once a month that focused on actual development strategies and best practices. Maybe each call could produce a working smart app that solved just one particular problem. I think the videos that would be produced by such calls would be more useful to new developers as they could see how different developers would use ST to solve a problem in a real world scenario.


+= z-wave device type fingerprints - how to differentiate very similar fingerprints. For example, the following are raw descriptions of two different z-wave switches:

0 0 0x1101 0 0 0 5 0x26 0x27 0x70 0x86 0x72

0 0 0x1101 0 0 0 7 0x26 0x27 0x73 0x70 0x86 0x72 0x77

The one with more command classes is a GE z-wave dimmer switch (part 12724) and the one with only 5 classes is a GE z-wave fan control (part 12730.) Adding insult to injury is that ST’s default “dimmer” device type only looks for 0x26. How can a device type specify that it’s ONLY for the “fan control” and not for a dimmer switch?

1 Like

:slight_smile: Sweet deal. I can’t wait to meet you guys in… like. 10 minutes.

I get an invalid meeting link…

Thanks, that did it.

1 Like

This got missed last night :frowning:

I also sent a query about it to support@, but got the following non-answer:

So… @April, @duncan, or @mager want to jump in and help?

Currently, I have two choices:

  1. Comment out the fingerprint entirely in the fan control device type, requiring that it’s manually set each time it’s needed. This is burdensome, and not user friendly at all.

  2. Query the device’s MSR (assuming it supports it) and use the MSR report to test for the specific GE Fan Control product ID… and change the device type on the fly to “dimmer switch” if it’s not. This is clunky (code-wise) and ties the device type to the single product from a single manufacturer. If GE/Jasco releases a product bump, or if Linear/Evolve/Cooper/Leviton have a fan control, the MSR checks would have to be changed.


1 Like

We’re aware that the current fingerprinting system is inadequate, and we’re working on an update to add at least manufacture/model and firmware version as fields you can match on.

Unfortunately in your case that fan switch is presenting itself as a dimmer switch – fan switches are supposed to use deviceId 0x1108. So, you won’t be able to get around hard-coding the MSR, though it will be easier when you can put it in the fingerprint instead of using the check-and-retype workaround.

oh? I wonder how much fun I’d have trying to report the “bug” to GE/Jasco. Would ST, as a member of the z-wave alliance, have better channels for reporting that issue to them?

In the meantime, thank you for the response.