Developer call 1/28 & calendar invite

Hey guys, since we met on the 14th, let’s keep our two week rhythm and meet on the 28th, same time:

Also, instead of keeping your eyes on this forum to know when the developer call is, send me your email using this form and I’ll add you to the official calendar invite:

We’re working on a public developer events calendar that I’ll share when it’s ready.

Finally, feel free to reply to this thread with suggestions for the 1/28 call.


Andrew - Topic I’d love to see explored is IP device integration and communication.

I have two specific use cases and the current documentation relative uPnP and discovery is VERY light in terms of actual use cases. I’m also confused as to if I need to go through the effort of creating a dedicated device type or not for these use cases.

Specifically in terms of device types, I’m trying to integrate a Beep home automation system. The device is uPnP for discovery, and uses and advanced HTTP header for persistence and state exchange. Everything in json just to keep it fun.

I’d obviously like a better understanding of the Sonos device type so that I can mirror the same capabilities and allow all the current Sonos integration to continue working without having to re-write or fork all that code.


1 Like

Perhaps we can carefully block a short window of time on the Agenda for this, if available?

I have several threads and messages in progress surrounding this Topic, but there hasn’t been broad participation, so the Call may be a way to rapidly collect some thoughts… (I can send you more info offline).

… CP / Terry.


I second a deep dive into capabilities.

  1. Capabilities Vs. Attributes
  2. What can be subscribed to?
  3. Best Practices
  4. Method for Adding Capabilities to official taxonomy
  5. Documentation. Documentation. Documentation.

Also method to add icons used in device types!!!

1 Like

I wouldn’t mind if a fairly blunt question was answered: With the v2 hub on the horizon, is any new dev (from ST) dead for the v1 hub?

(I imagine bug fixes might still occur, though I’m seriously starting to doubt that based on what I can see.)

Why does this matter? Because just as ST wouldn’t want to waste time on a near EOL product, “user-devs” might also prefer not to waste their time on a product that isn’t seeing active work from ST.

1 Like

Just a reminder to add all of your questions/topics here and sign up for the newsletter invite:

See you tomorrow.

Another topic that might be of interest:

How can device types communicate critical alerts (without the use of custom smartapps in the middle.)

For example: A z-wave door lock is detecting that a burglar is smashing the door lock (actual example would be the schlage touchscreen door lock “tamper” or “kick” alarms that send z-wave events to the controller.) Being that this is a device manufacturer specific alarm, not even a generic smartapp could handle it without some pre-defined protocol.

As a possible solution:

ST could implement a new capability: urgentAlert. This new cap indicates that a device is capable of generating (duh) urgent alerts. (Yes, this can be abused - but so can nearly everything else… I have great fun strobing the lights when my kids get home from school.)

Anyway, this new cap would have a single string attribute: “alert”. If a device type (such as a door lock) detects an urgent event (such as someone disassembling the door lock), it could create an event setting the “alert” attribute to some string, and the ST system would notify the user (as configured in a manner similar to battery or hub disconnected messages.)

An alternative is to just have the “alert” attribute of capability “urgentAlert” be a boolean, and then the descriptionText is used for the alert message.

(credit to @tgauchat for suggesting “urgentAlert” and pushing me to edit this message…)

1 Like

Same time as what? :wink:

5pm PST

@garyd9 Did you sign up for the invite?

I signed up (via the link) @mager but never got an invite… I’ll call in anyway. For some reason, tinkering with this stuff is too entertaining for me.

edit – er… not “call in”… it appears to be some kind of web-based conference.

@garyd9 Let me know if you got the invite!

There it is. Thank you.

1 Like

it will be helpful if ST staff can identify themselves with ‘(ST)’ after their names. Because it’s a conference call and anyone can talk, it’s hard to differentiate between staff or non staff


New release to discuss today!


The current Agenda items could certainly take up the whole hour, but, if there is time available…

I have a security concern related to Mode:

  1. Can you confirm that “changeMode(anymode)” can be called without being declared in SmartApp Preferences? i.e.,
  • From within any SmartApp?
  • From any Web Service that has access to any SmartApp (i.e., is there an API call equivalent to changeMode in the REST-API, and this call does not require explicit user authentication)?
  1. Is this a “loophole” within the user authorization process (for both native SmartApps and/or Web Services), in which users get granular control over which Devices the App is permitted to access? ie., While the user is aware they are granting access to their hub and certain devices, they may not be aware that they are granting read and/or write access to Location-Mode.

  2. If #1 and #2 are true, then is this possibly a serious security concern, since Mode is commonly used for “security sensitive information or event triggers”, for example:

  • Locks that unlock if Mode changes from “Away” to “Home”.
  • Alarms and Sirens that are disabled when Mode = “Home”.
  • and … Even read-only knowledge that a location is unoccupied (i.e., Mode = “Vacation”) makes that location more susceptible to intrusion (canceling out the benefits of simulated occupancy apps like random lights on/off).

For further discussion and a recommended possible SOLUTION (using Virtual Device Instances with “mode-like attributes” instead of Mode), please refer to this Topic/Post"

…CP / Terry.

1 Like