Universal ST/HE Driver code, differentiating between

🚧 Developers
1

Is there an easy way to determine if driver code is running in ST or HE (and therefore select blocks of driver/app code for each)?

I'm not finding a simple way to do that, but I'm also a n00b, so I might be missing something obvious (search is failing me).

Thanks!

2

I maybe misinterpreting your question. Tiles (not used in HE) are a dead giveaway that either the developer has not bothered to remove them or the code is intended for ST.

phsyicalgraph is another

3

This will generally result in a bloated device that's a compromise, you're much better off maintaining two repos.

1 Like
4

I get that. But there's really not that much diff between the two regarding this driver. Just handling things like physicalgraph vs hubitat, working around oddities, etc. Total diff is only probably 50 lines of code.

I mean more, can you call say (I know this is wrong, but) :

location.hubs.id.toString == "hubitat" vs == "smartthings" and then use if statements based on that?

5

I write code for a living, there's no convincing me this a good idea...
Put it this way, no one's going to think much of your driver if it's loaded with cruft...

3 Likes
6

in fairness, it's not mine. I'm asking for someone else who's trying to combine HE and ST code into single driver. I get what you're saying, but I can understand only wanting to maintain a single codebase.

Was just wondering if there was some way to do this... kinda sounds like not. =/

Not sure why we couldn't still provide some way to differentiate between the two... state.hubitat = true, or something... =/

7

Take a look at @tonesto7's Echo Speaks code. He's managed to get a single, rather large code base working for both platforms. That includes both app code and driver code, I believe.

I do agree with @mike.maxwell in terms of having separate code bases for each platform, but I have to give credit where credit's due when someone does manage to maintain a single code base for two disparate platforms.

2 Likes
8

great. I think the person has figured out a good check.

private getPlatform() {
	def p = "SmartThings"
    if (state.hubPlatform == null) {
        try { [dummy: "dummyVal"].encodeAsJson(); } catch (e) { p = "Hubitat" }
        // p = (location?.hubs[0]?.id?.toString()?.length() > 5) ? "SmartThings" : "Hubitat"
        // try { def foo = physicalgraph.device.hubAction.newInstance() } catch (e) { p = "Hubitat" }  // Not tested.
        state.hubPlatform = p
        log.debug "hubPlatform: (${state.hubPlatform})"
    }
    return state.hubPlatform
}

Some interesting notes. isNumber() and toInteger() are both technically string functions in Groovy. In Smartthings, if you run those against an integer, they just silently fail. In HE, it errors the code. =/

1 Like
9

Personally, I think that the Groovy implementation is heads and tails better in HE. Kudos to the devs for actually sticking to the standard.

2 Likes
10

totally agree. it's just weird differences that are like "what the hell?"

if I had to guess, and I'm just now dipping my toe in Groovy, I wonder if ST is just using a much older Groovy scheme (where things were looser)

11

Nope. ST basically codes to the lowest common denominator.

HE, and REALLY I appreciate this, allows developers to actually be developers.

1 Like
12

The easiest way for platform detection right now is to evaluate the value of location.hubs[0].name
On Hubitat it returns the hubs MAC Address. However in SmartThings it returns the name the user has given the hub.

For platform detection, this will work every time, unless someone has a SmartThings Hub with 5 colons in the name. :slight_smile:

def getPlatform()
{
    (location.hubs[0]?.name?.split(":")?.size() == 6) ? "Hubitat" : "SmartThings"
}

Then in usage...

if (platform == "SmartThings")
{
  // do something special for ST
}
2 Likes
13

The first check (encodeAsJson) is all well and good until we add that method to our Maps :slight_smile:

I like the second one ( location?.hubs[0]?.id?.toString()?.length() > 5). we use a number for our hub id (and its almost always 1)

1 Like
14

That is liable to change in the future, if it hasn't already.

15

Still works for now.. :slight_smile:

Your point is taken however.

16

What's the point if Groovy on ST is marked for death?
That's really the only reason I left ST.
Thank goodness I did...

3 Likes
17

I just installed a brand new Hubitat, and it's location.hubs[0].name comes out as "My New Hub" and I can't find any way to change it...

1 Like
18

Go to Settings, Locations...

1 Like
19

Thanks for the quick response, but Settings/Locations only allows me to change the name of my Location.

In fact, I can find nowhere in settings where "My New Hub" shows up, but it is in fact the string returned by location.hubs[0].name.

20

43%20PM

Yours looks like that?