SmartThings Community

Developer Help Needed. Device handler (DTH) ONLY works for Apple iOS ST Client but not for Android o/s

devices
android
bug

(Kurt Sanders) #1

I have created a simple device handler (DTH) for displaying personal weather data for Ambient Weather stations. The tile displays and works perfectly on Apple iOS devices :grinning:, but does not on Android devices :rage:. I do not own an Android device in which to test/debug and have been working with a user to test difference versions in an attempt to find the offending statement which causes Android devices to render “Something’s wrong. We can’t load your screen right now” .

I would love to have some expert help on:

  1. Review the Ambient Weather Station DTH code and hopefully help locate the issue for Android devices, and/or
  2. Recommend a way to emulate an Android device on a Mac and load the ST client for testing. I have tried several Android emulators that do not allow the ST client to load, like Bluestacks, Android Stduio, etc.
  3. Recommend a low cost Android o/s device to purchase that can load the ST client.

The SmartApp code works to sendEvents to the DTH, but visual display on Android is broken.


#2

I tried removing entries from the ‘details’ section. Initially I removed half and found I got tiles displayed fine. From then on the error changed to being displayed at the top of the screen instead. I initially decided the ‘refresh’ tile was an issue and then that it wasn’t. It is frustrating debugging a DTH as sometimes publishing seems to take effect immediately and other times it can take a little longer.

My last suspect was the ‘scheduleFreqMin’ tile and I notice there doesn’t seem to be a ‘scheduleFreqMin’ attribute which may have a bearing on your code elsewhere. I’m not convinced though.


(Kurt Sanders) #3

Thank you @orangebucket for your Android device testing of this DTH.

I added the attribute “scheduleFreqMin”, “string” to the current version of the DTH in the ‘master’ branch to be consistent with those in the beta branch which did have this attribute.

When I update the DTH in testing and then save/publish, I have to return to the home screen/room view of the ST client and then back into the DTH to see the changes. I agree with you, that sometimes these extra steps are not needed depending on what was changed in the DTH, but most of time, I perform these out/in steps to have the ST client re-read the DTH.

Do you think that:

  1. There is a limit of the number or sizes of valueTiles or standardTiles an Android client can display?
  2. Is the refresh valueTile and subroutine causing the issue on Android?

Is there a device handler that you can display on your Android device that works that I can review the DTH code that resembles what I have created? For example, can your Android display the SmartWeather tile, etc?


#4

I’ve had another play. I am pretty sure the problem is with the scheduleFreqMin tile and the background colours. I’d even go as far as saying the ‘Off’ value is the problem as if I remove that the DTH doesn’t give an error.


(Kurt Sanders) #5

:grinning: OK…

Let me try to correct that valueTile and test again…Thanks for finding the offending Android client statement…


#6
case 'scheduleFreqMin':
return [
    [value: 'Off',  color: "#FF0000"],

Just to avoid any confusion, I am talking about the TileBgColors method. My best guess is that the values are supposed to be integers (or at least numbers) and the value of ‘Off’ for scheduleFreqMin is breaking things when it comes to interpolating between colours. Why it should only be a problem in the Android client I wouldn’t know, unless you only notice on a fresh device install.


(Kurt Sanders) #7

Dear @orangebucket,

Would you be as so kind as to test this beta Ambient Weather Station Android DTH which has very simplified valueTiles. I removed any subroutines and hardcoded all state and attributeState sections.

The values for ‘scheduleFreqMin’ are defined in the DTH’s attribute section as a ‘string’ and are being supplied by the companion Ambient Weather Station SmartApp Service Manager as a string… Hopefully this is working, but if you find that commenting that section out in the DTH and getting it to successfully display on your Android will prompt me to remove that valueTile from the DTH and do something else to display the current refresh rate.

Here is the new valueTile section for the Android DTH. Note that the DTH does not have any subroutines other than those empty routines requited for DTH initial configuration and updates. I also removed the ‘Off’ value and will supply a zero as string value.

 valueTile("scheduleFreqMin", "device.scheduleFreqMin", inactiveLabel: false, width: 3, height: 1, decoration: "flat", wordWrap: true) {
        state "default", label: 'Run Every\n${currentValue} mins', backgroundColors: [
            [value: 0,    color: "#FF0000"],
            [value: 1',   color: "#9400D3"],
            [value: 2,    color: "#00FF00"],
            [value: 3,    color: "#458b74"],
            [value: 4,    color: "#FF7F00"],
            [value: 5,    color: "#4B0082"],
            [value: 10,   color: "#0000FF"],
            [value: 15,   color: "#00FF00"],
            [value: 30,   color: "#FFFF00"],
            [value: 60,   color: "#FF7F00"],
            [value: 180,  color: "#ff69b4"]
        ]    
    }

#8

It loads up the UI without error. What it does after that I wouldn’t know.


(Kurt Sanders) #9

Dear @orangebucket,

Thank you so much for your assistance. I think you located the Android specific area (valueTile scheduleFreqMin) that was being handled within the iOS St client but the Android ST client was not capable.

I will ask the Android tester with an Ambient Weather Station to verify!

tenor