Next Developer Call will be on 3/11/2015

General Discussion Groups & Events
1

Next Developer Call will be on 3/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

The previous developer’s discussion here:

Summary:

Mager, Ben, and Tyler on the roof of SOMA, but they won’t disclose where. Mager is very secretive.
Jim Took Nyquil instead of Dayquil, so he felt like it was his day off.

I need to tackle the laundry monster in the back of camera. Wednesdays is laundry day, but now it’s forever on the internet, and will forever haunt me :frowning:

Discussion starts at
6:45 - Going through the Agenda.
9:08: TreeHacks : Treehacks update, 500 people there, 5 projects built.
If there’s any events in any area, we’re building our Ambassador’s program.

  • From a learning docs perspective, we got some ideas on onboarding procedures for Documentations, since TreeHacks.
    Moving forward: At events, live updates at the threads itself.
    Capabilties: We are looking through them, we have engineers looking at them. On the interim, we will adding a kind of integration, voting system.

SmartApps submissions still going by, if there’s one you’re waiting for, Tag @Mager, and he will push it through.

Gilbert: Clarification on DeviceTypes: Sometimes, it’s not the manpower, but relationship between the partners.

18:05 - Tyler added 5 additional sensors:
Fibaro motion, flood, door/window sensors
Cree zigbee bulb
WeMo Zigbee Bulb
Tyler goes into how a device gets certified, but takeaway is: More devices being certified more frequently.

20:00 - Gilbert’s update:
Starting a new initiative, “Device Health” : The ability to DeviceTypes to report back to the platform the health of the product. To increase reliability of SmartApps and DeviceTypes, and deliver a better experience than today.
26:53 - Eric’s question regarding: Z-Wave fingerprint using the Manufacturer’s Specific Command Class.
35:58 - Gary : Sunrise/Sunset
39:39 - Jody asking about wider API access
43:43 - Ash asked about crashing Smartapps especially on cloud
45:51 - mike : No documentation on huhAction, childDevices
53:44 - GE bulbs - Why does devices ask for two parameters, but it fails when you provide two?
1:01:20 - Jim gives a shout out Gary for finding a bug in the documentations

Cheers.

2

Topic: Bug fix priorities:

When choosing bugs to fix, does ST give any priority to “low hanging fruit?” As a developer that contributes freely to ST, I get frustrated when I see bugs reported to ST that include potential fixes - that are trivial things to fix, but that never seem to get fixed. These are things that all a ST engineer would have to do would be cut/paste the suggested fix for (and are plainly obvious.)

I really start losing enthusiasm for the product when I see these types of things dragging on for months. What is someone like me supposed to think when ST apparently isn’t interested in fixing these tiny things? What does that say about the bugs that might require actual effort to fix?

For example:

(which was previously reported almost a month earlier):

(The irony is that this particular issue isn’t actually seen due to a larger bug that the device type never queries the configuration parameter and just assumes that the set cmds worked… Which, btw, would be nearly as trivial to fix.)

Edit: I hope ST doesn’t take offense to me calling these things out like this. However, as one of the great positives of ST is the community development contributions, I feel that those community developers have a right to ask these questions.

3 Likes
3

Gary, don’t ever feel like we’re taking offense to being called out on. The community’s contributions like this are one of the biggest things that calls to our attention to what we should work on. I am thankful you bring to light these, and encourage you and everyone to do so.

We’re always striving to improve : our platform, our decisions on how we handle things, and well, just everything. We’re always improving. These comments and ‘call outs’ assist us in our ongoing efforts to improve.

In short- Thanks.

4

agenda +=

@April and horse masks. ( Having issues installing a smartapp )

2 Likes
5

Man, where do i get one of those obnoxious looking masks? The more obnoxious, the better.

6

You’re near the SF Bay area, right? It shouldn’t be a problem to find anything that anyone (sane or not) would consider to be “art.”

1 Like
7

Was the video from the last call ever posted?

8

I would like ST to weigh in on "community supported methods and documentation"
It’s obvious there exist methods and procedures within the production code base, that are being considered unsupported for community use, and yet example code contains these gems.

I would like to know where ST stands on this, and if these nuggets are to remain unpublished, but developers can use them, how to I get access to this tribal knowledge, AKA, good’ol boys club…

Also an update on the “childDevice delete” patch would be helpful, particularly with my own sanity maintenance…

9

No.
There is a delay on our end. We’re going to try to put it up as soon as we can. Apologize for any inconvenience.

Cheers!

10

If anyone has questions related to our device certification efforts please ask here so I can prepare for the call.

11

I have a question on device certifications… :grin:

What does it mean when a device is certified?

Also, (I know I said “a question”), does SmartThings support issues with OEM functionality? Or, does SmartThings provide OEM contact info to resolve a problem?

And another… If a device certified, does that mean all device functionality is exposed and incorporated into SmartThings?

12

Great questions Todd! We’re planning on a segment about this for a future developer call, but let me outline some things here and we’ll see what we can do for tomorrow.

A device is marked as certified when it has passed a series of test procedures. At a minimum this includes a code review of the Device Type, three successful test plan executions, and a final functional/experience test prior to publication.

This is similar to the process we’ve always used for releasing new devices. There are some changes and improvements that we’ve made in the recent weeks:

  1. We’ve created a framework for a Community Beta program. We expect to release a new device into this beta program within the next month. We will be inviting people who actively contribute to this forum into the beta program and you’ll get to test out a new device (and in most cases keep it). We’ll be using the feedback from the beta tests to improve the integrations as well as inform decisions related to our products and services as a whole.
  2. We’ve increased our capacity to process Community-submitted Device Types and we’re continuing to hire in to these positions. Want to help shape the future of SmartThings? Here are some positions you may be interested in:

Device Certification Engineer - Palo Alto
Software Development Engineer, Devices - Palo Alto
Software Development Engineer, Solutions (SmartApps) - Palo Alto

Our Support organization tries really hard to not draw a line when it comes to troubleshooting devices that work with SmartThings. Our Support team receives training on every device that we add to our ecosystem and has access to the physical devices if they need to test something out. We’ll definitely provide contact information for third party support departments, but only if that speaks to the quickest and best resolution for the user.

Not yet.

There are several examples of devices being certified but not having every feature supported on our side. One obvious example is lock code management. Expect to see fewer incomplete integrations moving forward, but I don’t think we’ll have a requirement that certified devices expose all functionality.

13

@Tyler

I would like to know of official device certifications for the following devices:

Linear GD00Z-4 Garage Door Controller

Iris - Waxman Water Shut Off Valve

Thanks!!
:+1:

14

@Tyler, being you opened the door on it… What is the latest status on device type certifications? I’m curious for selfish reasons: I have a device type update I submitted back in Jan that’s still showing a status of “submitted.”

15

Also related to device type certifications, can I get an “official” comment on this:

If ST is good with the idea, the modifications needed for the existing device type would take less than an hour.

16

agenda +=

A forum section was created to discuss adding new device capability types. Has ST decided anything in regards to any of the suggestions? IF any were to get added, how would ST notify the user-dev community?

1 Like
17

I am also interested in hearing this.

18

Both are pending certification. The good news is that they work with generic device types (and rather well I hear). The Waxman valve will pair as a ZigBee Water Valve and the GD00Z-4 will pair as a Z-Wave Garage Door Opener.

We’re waiting on a platform change to allow the GD00Z-4 to be used in the Doors & Locks section of the app, then we’ll test it out officially.

We’re working faster than ever to review and approve submissions. Unfortunately we’re behind, but see #2 in my answer above:

Duncan wrote our lock implementation, so his answer is more important than mine. :slight_smile: Whenever we see suggestions like this on the forum we route them to the correct person on our end. I’ll follow up on this one.

19

Please don’t be surprised if I nag about this one continuously. The code changes required would have no impact on functionality for the device or any existing smartApps (100% backwards compatible), but would allow much smoother interactions with smart apps. In other words, a lot of potential positive for nearly zero risk. (See my comments early in this thread about “low hanging fruit.”) In addition, it provides an excellent template for how future device types might pass extra data along with attribute events.

Take care
Gary

20

@greg, the first post is now updated with a link of the video and some timestamp references. Hope to see you tonight!

2 Likes