I’d be interested in this kind of driver!
The official Hue integration already gives you two choices:
Cloud to cloud
Or
Local LAN (requires a smartthings hub)
It’s one of the only non-zigbee/non-Z wave integrations which has been local for several years.
What it doesn’t give you (With either method) is access to Hue scenes or Hue accessories.
Also…
This
the IP and Hue Group ID
Doesn’t work because one of the main issues with Hue and third-party integrations is that they don’t have a unique group or scene ID. It’s all context sensitive based on the room that you’re in. This is the primary reason that hue scenes are not exposed to most other platforms, not even HomeKit. (This is technically called a “waterfall naming convention“ if anybody cares. 
)
Alexa did it by attaching the hue room name to the scene name, but many platforms don’t allow you to have a scene name that is that long.
They added “zones” a year or two ago specifically to address this integration issue, but most people don’t use those.
So you may want to visit the hue developer community before getting too deep into all of this stuff, the architecture is unique.
It also doesn’t give you access to Hue Rooms or Hue Zones. When I refer the Hue Lighting Groups, this is what I mean. Each Hue Room/Zone gets a unique ID that you can use to set a scene on it. Each scene is also given a unique ID and is assigned to a room or zone. This is what Alexa imported. I want to import both Hue Groups and Hue Scenes, but control things through the Group. I can do all of this via REST. This Web Requestor will be capable once PUT is added. Once it is available, I’d be happy to do a writeup on integrating Hue Room/Zone control using the Web Requestor. It makes a good stop gap until a better driver is available
@JDRoberts How can I spin this content out of here into a new thread? I have seen it done a few times when a thread goes off the rails.
1 Like
@TAustin The Bond bridge is another api that would be interesting to setup using your web requestor, but their Local api requires passing a token in either the header or via a json body like so. This also applies to GET commands.
curl -H "BOND-Token: f074b61f628018fd" -i http://192.100.0.61/v2/devices
curl -i http://192.100.0.61/v2/devices -X GET -d "{\"_token\": \"f074b61f628018fd\"}"
Each web call could have a name, command, address and body. Then they could also be named for easy recall. If this is outside your scope, let me know and I may go that route on my own thing.
So if I go ahead and add a field in the device details screen that gives you a way to provide whatever you want to include in a body, I think that would give you want you need, including for the Bond bridge example. Yes? If you need multiple requests each with their own body, then you can just create multiple devices.
I’ll leave the 50 configurable requests available through settings alone - continuing to be just simple URI-only requests. There are several folks using it that way, so I don’t want to disrupt it.
Ever since I added ability to create multiple devices, that opened the door to having more customized, individual web requests more useful for customizing or using in automations, defining return keys to be parsed out, and now defining a body to be sent with the request.
2 Likes
That would be awesome. Your existing edge drivers are fantastic. Thanks.
1 Like
Just curious: the maximum of 200 devices per location applies to virtual groovy devices as well as physical ones. Edge drivers for virtual devices count against that as well, right?
Thanks for reaching out, I’m discussing this with the internal team, I’ll come back here once I know more 
3 Likes
@nayelyz Is it 200 per hub, or per ST account? Not sure why virtual devices would count against a hub. Seems like the hub would only be involved with zigbee/zwave/LAN
It’s 200 per SmartThings location (for regions outside USA. It was lifted in the USA)
2 Likes
Interesting disparity
I wonder what the rationale was for this? If it can be technically lifted, I’m not sure why it would be left in place for some users and not others. Maybe it is bandwidth related and they can push more traffic on the US servers. Just guessing.
If it is due to bandwidth, maybe they can lift it for all when more local processing takes hold
My understanding is that it’s the other way around: as they start doing more local processing, they run the risk of customers’ hubs becoming overloaded, so they need to put some guardrails in place. Virtual devices will take pretty much the same amount of memory and processing on a hub as a physical device, so that’s why they would fall under the same limits.
We already see this in some of the competitor hubs which run everything locally except third-party integrations. The usual solution there is to add another hub to help carry the load, but that’s not easy under the smartthings architecture. But you will find quite a few customers of Homeseer, hubitat, and Vera running more than one hub as their networks expand, just to name some examples.
But we should take this conversation to the guardrails topic:
FAQ: Limits and Guardrails (max # of automations, devices, etc)
1 Like
Do you think this would work for the switchbot stuff we talked about earlier in the thread?
1 Like
A conundrum. I need to update my app to use this, yet I see many here whose devices disappeared etc when they update. Sheesh lol
Is anyone using the Web Requestor to do anything with LIFX?
Hi again, @TAustin, @blueyetisoftware.
Yes, there’s a limit of 200 devices allowed per location, if we had more than that number of devices in the location, the app performance could be affected.
The virtual devices and cloud-connected devices are also counted; the limit restriction is the same for all the regions.
2 Likes
There’s an open goal if ever I saw one. Who wants the first go?
2 Likes
@TAustin Following on from the comments about {state_change = true} on the virtual devices thread, that could have an application in this driver.
When calling a device via a Rule, the httpcode attribute isn’t first cleared as it is when using the UI, however the response is, whereas the response is set to --. This means that the httpcode only propagates when it changes.
So, for example, I ping a TV every five minutes. When it is off I get a ** Timeout and when it is on I get a 200. so if I turn the telly on at 6pm and off at 10pm I get the 200 at 6pm and the ** Timeout at 10pm and nothing in between. However I do see two response every five minutes - the -- and the actual reply.
Arguably the code could benefit from the {state_change = true} so it is always propagated on every web request (so it can be triggered off).
It could also be argued that the response could use it so that the preliminary -- is unnecessary, but you probably still need to clear the response somewhere so it is swings and roundabouts.