Platform Update - Release Notes - 02/17/2015

Platform Update - Release Notes February 17, 2015

General Platform Updates:

  • Improvements related to removed device handling
  • Improvements related to user account management

Developer Updates:

  • Allow SmartApps and Device-type Handlers to iterate request headers via request.getHeaderNames()
  • IDE now verifies all input names are unique on save.

Recent documentation updates:

6 Likes

The embedded URL is missing from this sentence (?). It is blue, but hover reveals no link…

1 Like

Oops! :open_mouth:

Should be fixed now. Thanks for catching it!

1 Like

Thanks for fixing the link.

But now the “concern” … oh… doc enhancement request?

If the attribute does not have any possible values (for example, “battery”), you would just use the attribute name.

This is inaccurate and unncessary, IMHO: The Attribute capability.battery.battery most certain does have “possible values”. It has a value from 0 to 100 representing the percentage power level of the battery.

The syntax or semantic problem isn’t yours, it is the titles of the Capability Document:

I recommend “[possible values]” column header be changed to “[data type, valid enumerated values, or valid range]” or something similar.


The “no value” syntax of subscribe() is valid for all Attributes, even if they don’t have an enumerated list of “possible values”. Without a value name, the subscription applies to (and fires upon) any change in the value of the Attribute. (Which you do describe in the next sub-section Subscribe to All Device Events.

Is this documented? Or an example maybe? I search the docs and it came back empty.

We have on our backlog work to better document web-services in general, and this falls into that. For now, know that request.getHeaderNames() returns an enumeration of the header strings:

request.getHeaderNames().each {
    log.debug "header: ${it}"
    log.debug "header instance of String? ${it instanceof String}" // => true
}

We’re working towards ensuring that bug fixes / features are documented as they roll out, but aren’t all the way there yet. But we wanted developers to know that they can get the request header names now, as they might in other frameworks.

1 Like

I was trying to communicate how one would create a subscription for attributes that have no discrete values, for lack of a better term. In the battery case, you would subscribe to “battery”, not “battery.battery”. There would be a value in the event for battery as you described. But yes, the way they are described in the capabilities taxonomy is not entirely clear/thorough at the moment.

Well…: The better “term” is that which you just used :smile: – “no discrete values” (or no “enumerated” values, as I called them, but discrete is fine).

Using my own words against me! :stuck_out_tongue:

I’ll try and clarify it. Probably tomorrow.

Like the new format of the release notes. Groupings make it easy to focus on “front end” vs “back end”, shall we say.

3 Likes

Hmm… any changes that might affect the Nest device type?

It appears some HTTPS authenticated integrations are going haywire last few hours. Can’t control Nest temp setting, no Nest device log activity since 2:43PM PST. Loading Nest thing activity feed causes Android mobile app to crash. Log errors:
9:23:30 PM: error java.lang.NullPointerException: Cannot get property ‘uri’ on null object @ line 520
9:24:56 PM: error groovyx.net.http.HttpResponseException: Too Many Requests @ line 565

Ubi lost its association. Re-authorized Ubi and now seeing more than 48 log entries per second in live logs. Yet integration seems to be working for Ubi announcements. Log error: physicalgraph.app.exception.SmartAppException: Device not found @ line 463

And MyQ control works, but no logs of event open/close activity since 5:57PM PST.
error java.lang.NullPointerException: Cannot invoke method toLong() on null object @ line 475

@Jim, Could you elaborate what is being checked? I’m getting this error on save that I have not seen previously:

You have multiple inputs with the same name

… but there’s no line number or input name to reference the code. This is not very helpful. I checked and re-checked my code and I can’t see any duplicate names. I even went as far as commenting out all inputs and I’m still getting this error.

1 Like

I’ll ask about providing a more informative message.

Can you post your code or a sample that is giving the error? By chance does a browser refresh fix it (wouldn’t expect so, but I always do a hard browser refresh whenever I’m having any issues in a web client. Old habit :slight_smile: )

Not sure if related to all the new releases, but since all the updating, IDE will not let me delete a DeviceType, error says - DeviceType still in use by devices.

Yet it is not in my list of current devices or being used?

Support has been looking at it a few days, anyone else having similar. I can create a new one and delete it fine…

I have the same problem, can’t delete…just disabled.
Chris

I’ve been having issues with publiching and installing device types in the IDE for debugging. I started getting “cacheloader returned null for key” errors for those two operations. I switched to a copy of the same device type, which did not present me with that error, but when I installed it on the same local device for debugging logging, the output looked like it was still from the last version of the original device-type that I was able to debug. Then the simulator stopped working for me altogether.

I deleted the copy, and I’m not getting the cacheloader errors anymore, but selecting location just spins and doesn’t complete.

@ccitarella,

Just email support@smartthings.com and they will fix it for you…

I don’t know if this will help anyone but I had the same issue with the delete problem. I had deleted the device itself but the device type wouldn’t clear stating that it was in use by a device. Using the simulator in the ide I did an install and then an uninstall. After that the devicetype would let me delete. I hope that helps.

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.