Tips on debugging Device Type Handler crashing Android app?

So, I’m in the process of creating a virtual version of the ZigBee RGBW Bulb. Which in itself should be simple enough. I’ve taken the official Device Type Handler (https://github.com/workingmonk/SmartThingsPublic/blob/zigbee_rgwb/devicetypes/smartthings/zigbee-rgbw-bulb.src/zigbee-rgbw-bulb.groovy) and gutted it to be a bare bones logging only for all the event handlers. I can create a new device through the web console without any issues. It shows up in my “things” on the Android mobile app and I can access it ONCE. Just once. After I pull up the detail and exit any further attempts to bring up the device details crashes the Android app. Deleting and recreating the device gets me ONE more shot at using it before any further attempts to access the details crashes the Android app.

So my question is: Any advice on how to debug this? There isn’t anything logged in “Live Logging” when it crashes. All interactions with it prior to crashing show up just fine in the logs and everything works as expected.

There is no logic at all in this device type handler and it’s really just a gutted version of the official one. I’m really stumped and beginning to get a bit frustrated.

I love ST and Groovy (and Grails) and I spend 10+ hours using Groovy/Grails/Java/Spring/etc. every day (professionally). I’d like to become a very productive member of the ST development community but little things like this and the inability to run the simulator for even some simple SmartApps is beginning to make me wonder how I’m going to do that …

1 Like

I don’t remember Android handling the multiAttributeTile very well. You may want to convert it to a basic tile.

1 Like

Thanks, I’ll give that a shot, but it seems odd that the official device type handler doesn’t seem to have any issues at all with this (nor do others, including some user created ones).

It’s worth a shot. I’ll see if that brings some stability. Thanks again!

Well, I’ve narrowed it down further and I’m still confused. In the process of converting it over to basic tiles I found that as soon as the color control is added it no longer works beyond the first time.

I’m a little lost now, so any assistance in further debugging would be helpful.

Here is the control defined (still using basic tiles):

    controlTile("rgbSelector", "device.color", "color", height: 3, width: 3) {
        state "color", action:"color control.setColor"
    }

And of course the device has:
capability “Color Control”

And the associated:
def setColor(value){
log.debug “setColor(${value})”
}

@JoshuaMoore

I have noticed that if there is a null value stored in the device’s “Current States” (check the actual device in the IDE), then it will crash the Android app. Check to see if there is a null value there. If there is, you will have to modify your device handler to prevent this from happening.

2 Likes

This is very close to what was happening. What was happening was the state for “color” was the entire map (hue, sat, level, hex, etc.) instead of just the hex which apparently the color control is expecting.

Seems silly that this was the case, but manually putting a hex value there and sending the hex value from the handler value map seems to have resolved this issue.

Now it’s a matter of the app that uses this device converting said hex color into HSL for use by the actual devices it controls.

What a pain :confused: