ST Edge Driver Conflict

@nayelyz Do you know if the ST team has started rolling out their own Philips Hue edge driver? I have one user that was unable to get through pairing because it kept selecting a different Hue driver built by ST. To use my driver, the users need to go to discovery, scan nearby, and press the pairing button on their Hue hub. After pairing, the Hue hub locks itself. It looks like a different driver was grabbing that pairing and my driver was being shut out. It was very difficult to get him past that.

I am hoping that there isn’t a rollout that will result in a big conflict. Do you know if they are rolling that out? Are you able to connect me with anyone that can confirm the discovery process?

Mmm how did you do it? in order of preference, installed drivers (in this case yours) should be used first. Let me ask the team.

He kept trying to delete the ST device and it would re-grab the pairing each time. I had him leave the ST device in place instead and go to discovery again. Since the ST device already existed, we were able to grab the pairing the second time through.

Thanks for sharing this.
I asked the team and they also mentioned this workaround, so you were correct about doing this.
The current issue with this specific LAN integration is that it cannot filter which option to choose: installed drivers, or a stock DTH because it has no fingerprints to compare the device with.

Once the Edge driver of ST is available in the default channel, the option to install the Groovy integration will be blocked. This is because some people aren’t present in the Community to install one like yours so they can only get the handler by default and if the ST Edge driver isn’t available yet, they won’t be able to integrate their device.

There’s no ETA for that yet, so, this behavior is expected for now. Sorry about that.

This is the first time I have seen the “scan nearby” workflow pick up the stock DTH. I thought that was only available by going through the branded Philips Hue workflow. Should the DTH even be loaded through “scan nearby”? Since I haven’t seen it before this, should I assume my driver and the DTH are essentially racing each other for that pairing token?

The user sees a Hue device, but it isn’t even my driver, so I end up trying to answer support questions only to find out it is the wrong driver.

I would suggest to the team that it would be a better experience if the app let you choose a driver in the same way you choose a device type or choose a brand. Then we run discovery with just that driver.

Yes, the team mentioned that “scan nearby” can also call the Groovy integration.

Yes, the first in claiming the API key is the one paired to the device.

So, when you thought you solved this issue it turned out that the device is not using the correct driver?

I’ll share this with them, currently, we’re in the middle of the platform transition so, this process should improve as well.

We did work around it. I just meant it took a while to figure out I was dealing with the DTH and not my driver. :slight_smile:

1 Like

Aaah ok, got it. The good thing is that this kind of case provides more experience :smiley:

Just in case you don’t know already, an easy check-up to see if it’s Groovy-based or Edge-based is if the “Driver” menu appears in the device detail view.

Yeah, we checked that. Not sure if you are aware, but I frequently see that Driver entry missing from the menu for Edge devices. If I keep going in and out of the detail view, it eventually shows up.

1 Like

:thinking: I only heard there were some issues if you weren’t the location owner, but it also happened to me when I opened the app too fast…
If this is very frequent we can open a report about that but I would need your help to collect the logs from the mobile app :smiley:

This is how I do it as well. Just running into the device too quickly to check functionality while working on drivers.

Yes, that would be a great improvement! Some of us are currently having a lot of colliding drivers and as we know some init work for several devices need to be done during binding procedure so changing the driver after that would not help.

I can confirm that I have exactly the same issue. I think previously the problem was only when entering the menu too fast or if we weren’t the location owner but now it happens very often and sometimes even “going in and out” doesn’t help. I need to force close the app to make it work.