[ST Edge] Philips Hue LAN [BETA] (3rd Party Driver, Not ST Native)

You won’t be able to get around the issue. ST is working on a fix for their cloud, which is required when adding devices. I know it is being worked on. I would just hold tight.

It sounds like you are using the ST cloud driver which explains why they come and go. It is unrelated to the bug they are fixing.

1 Like

I started to migrate my Hue lights to this great edge driver but have come across an issue. I have a simple Routine that uses a motion sensor to turn on six individual spotlights in a room (“Cave”) and another to turn them off if there’s no motion. I have used the driver to add the room and now just have “Cave Lights” instead of the individual lights and can play a Hue scene as a Favourite in the “on” routing. That’s a nice simplification and works fine to turn on the lights. However the “off” routine isn’t working, including when I “Test routine actions”, so what am I doing wrong here?

Edit: Having not worked earlier, and without me changing anything, I just noticed that the “off” routine is now working. I edited the routine and ran “Test routine actions” again and this now works fine, turning off the lights. Most odd, but I will assume this is something local and nothing to do with the edge driver, though I’d be interested to know if anyone else has had a similar glitch and identified the cause.

From the driver side, all I can think of is the driver restarting or Hue going through an update of some sort. If you tested those at the same time, and only one worked, I would lean toward an issue with the automation portion of the app.

I wasn’t aware of any updates or restarts, but that doesn’t mean they weren’t happening of course. The only thing I’ve just noticed is that the six Hue lights I removed once I got your single Room device set up have now reappeared. I assume that this is just the ST-Hue integration doing its thing and I guess they’ll reappear once more if I delete them, so I just move them into an “unused” room until I delete the original Hue bridge device and rely solely on your device for it.

1 Like

Bumping this as more people keep asking… The ST team still hasn’t released a fix for their cloud yet and this driver, among others, will not be able to create devices until they do.

1 Like

Oh yes, I do have lights grouped in the hue app and some groups such as bedside lamps in their own room/group as I have two lamps and to get individual control of each lamp with its own hue dimmer remote I have to have them in separate rooms.

The only reason I even mentioned the ST lighting groups was because i thought it would be a good work around to allow me to dim my lamp once my bedtime routine starts.

My original post was more wondering if there was any way to add the same level of control that is found in the Zigbee light multifunction MC edge driver that I use with my tradfri lights to your hue beta edge driver as it would make what is already an amazing driver and one of the most useful additions to ST ever even more powerful.

1 Like

I see. My original intent was to have the driver trigger Hue automations. So you would create a wakeup or nighttime routine in Hue and then trigger it from ST. Their API doesn’t allow for that yet, but I see bits and pieces of it in there.

@stillerson @leonardo @Jeff_Gallagher and others that cannot create devices. Check out this post. ST is still working on a fix, but they have a temporary workaround. You will need to send them your location ID. Keep in mind that you should do that directly with them over DM, as it is unique to your setup.

4 Likes

Perfect thanks

I’m not saying that this is 100% the issue or how related it is to the issue, but apparently I had an old device (from Echo Speaks) that was somehow stuck in my account. There was no way for me to see this or remove it but it was suggested that it was causing a problem in creating child devices. I believe I was able to see this device in the old IDE so when they rolled out the new platform, I’m wondering if some things were lost in the ethos.

Thanks for the info but that wouldn’t impact this driver. The device IDs are not shared. The issue with child devices has been verified to be a ST cloud issue and they are trying to resolve it. They are able to setup a workaround for you if you DM them per the message above. After that workaround, you may still see timeout issues that they are also trying to resolve. Unfortunately, the ST cloud impacts device creation even though the driver itself executes locally.

1 Like

Gotcha. It came up after DM’ing my location ID to nayelyz and she said the developers asked if I could delete the invisibile device to see if that was causing an issue.

On another note, they did use my location ID for the fix bc I was able to “import” all my hue devices with your driver. I don’t seem to have any conflict issues but I currently have duplicates for all my lights. Would it be safe to delete the ST Hue hub (from their default driver)? I’d like to keep things clean.

1 Like

Hi, @leonardo
So, were you able to install all of the Hue devices now? The bridge is the parent and the connected devices are the child devices.
About seeing duplicated devices, I think it’s because you have the official Cloud-To-Cloud integration.
You can identify them in the Advanced users’ app > Devices, one instance of the device will have a type of “VIPER”. After confirming that, you can delete all of them if you follow these steps:

  1. In the ST app, go to the Menu
  2. Enter the settings of the app, then look for the option “Linked Services”
  3. Then, tap on the three-dot symbol in the upper-right corner and select “Unlink”
  4. It will show a “-” symbol next to each service, so, just click on the one next to “Philips Hue”
  5. Confirm the process by tapping on “Unlink” in the pop-up
1 Like

I have two Hue lights in a room and one Hue scenes, one that turns one light red and the other that turns one light green. Both leave the second light off. I have created two scenes manual routines in ST, each of which just turns on the Room lights (a device created by this edge driver) with Play a Favourite set to the Hue scene name. They work fine, except that the second light briefly flashes white before going off again. When I switch between the two scenes in the Hue app, the second light never comes on, as expected. Is this a feature of the driver or is there something I can do to fix this?

It’s not limited to one room or scene as I noticed a similar behaviour in a bathroom nightlight automation which plays a Hue scene with a single light at 1% but which initially comes on bright before dimming, which doesn’t happen when I play the scene from the Hue app.

Yes. If you are happy with this driver, you can unlink your official ST integration to get rid of the duplicates.

It’s not a feature of the driver :slight_smile:

I’m guessing your automation turns the room “ON” before playing the scene. ST defaults that to ON for some reason, and you have to un-click it if you don’t want to change the on/off state. That is probably the cause of your brief flash before the scene kicks in.

1 Like

The API was just published for Hue contact sensors and Hue cameras. If anyone want to buy me one, I’ll happily integrate them :slight_smile:

3 Likes

Ah, yes, that is indeed the issue. It looks like an option group and it never occurred to me that I could untick ON and leave all options blank. I should have tried that, so apologies and thanks.

1 Like

I’m not sure what you mean with the device having a type of “VIPER”. I do not see that anywhere in my device list.

Go to the Advanced page in the web interface.

my.SmartThings.com/advanced

On the devices list, Choose a device by clicking on its name label and go to its details page.

You will see a line with the columns manufacturer code, model, and type.

If it’s a cloud to cloud integration, it will say “viper“ under type. (That’s just smartthings terminology, you won’t see it anywhere else.)

In this screenshot for a device named “Atomic,”, it’s just to the right of the fields that were marked in red.