I've done this. Works great. I hate to use an extra hub just for this....but oh well. I wished a hue emulator was available for Hubitat.
Edit: I didn't unplug my ST hub though.
1 Like
I believe you only need a powered on hub initially. I've read several reports of people working with the power off on the ST hub itself. Obviously that can Only work if it's cloud only execution. Anything needing to interact with a physically paired/joined device to the ST hub must have the hub powered.
Long ago, I have turned my ST hub off and did ST Classic app interaction with Hubitat devices.. meaning I used the ST app as a 'dashboard'. So I know it did work.
1 Like
The older, still-built-in Echo App (not Alexa Skill app) basically does this, but I'm not sure how closely it pretends to be a Hue Bridge or what kinds of devices it exposes (but it was/is enough to trick an Echo into adding it like it's a Hue Bridge). I do think I read somewhere where someone didn't have luck using it for this purpose, and I definitely know you can't use both it and the Alexa Skill, which is better in pretty much every respect unless you're in a region that doesn't support it. I don't think a community app could fill this gap since Hue requires specific URLs and you probably need the special power of a built-in app to get that. I do wonder if you could use diyhue on other hardware and tie it into Hubitat, possibly with virtual devices, for this purpose, but it would still probably need to be modified to get these there.... 
For me it’s an ethics decision. Removing the hub requirement basically would enable anyone to sign up for a ST account and use their cloud resources and integration with Hubitat without actually purchasing any SmartThings products and services. Flipping that around, I think many of us would be unhappy if someone created an app on another platform that used Hubitats cloud infrastructure without having to purchase a hub.
That said, I’ve given the issue some thought and I consider the install crashing out on a lack of a hub to be a bug in the hub detection code. I’m going to modify the remote code to return null when the app fails to return a hub which might have the side effect of allowing installation to continue without a hub.
The official HubConnect position on this shall still keep with the requirement for a physical hub. If it happens to install without one, well that’s a “bug” I’ll have to deal with someday. 
5 Likes
I see your point regarding using the ST platform without buying any Samsung/SmartThings hardware. At the same time, Samsung is pushing that exact model with their support of tons of non-Samsung cloud services, WiFi devices, and the removal of the requirement to have a ST Hub. So, I don't know that Samsung would really have an issue...
Plenty of users have a Samsung/SmartThings account without a hub. They buy Amazon Alexa/Google Home devices, WiFi switches, dimmers, bulbs, thermostats, Harmony Hubs, etc... from various vendors... and then tie it altogether with a SmartThings account for cloud-2-cloud integrations. Hopefully, having Hubitat as one of those C2C integrations would not be an issue...
Samsung appears to encourage this, IMHO, because the customer data is their product. I really doubt Samsung makes any profit on the SmartThings platform from hardware sales when one considers the cost of their cloud infrastructure. Selling customer data, though, has to be where the real $$ is.
That said, no one should abuse the ST Platform, in my opinion. Using it alongside of Hubitat for a few integrations seems like a reasonable solution. Options are a good thing! 
I don't disagee with any of this. But such a use could fall outside of SmartThings agreements with their cloud partners and that's why I feel it necessary to tread very lightly on this. If they choose to block HubConnect, as they did with ArloPilot, we all lose.
And since HubConnect allows a user to connect any of their cloud-integrated partner devices, and I am not a Samsung Partner, I would say that the risk of the app being blocked is above a comfortable baseline.
Edit: The "fix" for the mac address error will be in HubConnect 2.0.. Beta testers will see it in Beta 4.
3 Likes
Very true.
Also, it literally costs less than $40 to get a v2 hub and use the ST cloud/platform with HubConnect. To put things in perspective, that's less than a couple drinks at an NFL or NBA game ....
3 Likes
doesn't ST have a responsibility too? If they never make a linkage between a purchase and their services, is it up to me to protect them?
In other words if I tell a neighbor "ST would solve that", then they go and create a ST account to learn about it's features... only to find out that they don't need to buy anything from ST. Is it my duty to let ST know?? or 'force' the neighbor to buy ?
Of course.. But SmartThings has the right to ban any app from their platform. That's a fact that's always in my rear view mirror at all times. Simply that they allow hubless accounts is not an open invitation to developers to create bridging apps that effectively allow users to bypass their platform.
They banned ArloPilot because Arlo complained about a 3rd party app accessing their services and it was shut down.. No notification or justification (at the time). Bam. Done. Don't think it couldn't happen to HubConnect. All that it would take is Arlo, Ring, or some other 3rd party to complain and the switch gets thrown. I doubt that will ever happen... However I'm not going to buy into the "because you can, you should" login on this topic. There is more at stake here..
Except if it is.. they monetize the data. Where the data comes from is probably low on their consideration scale. It is possible that by pushing a small or large portion of your Hubitat data into ST's cloud, they are patting themselves on the back for acquiring data 'for free' that they can monetize.
We will have to agree to disagree on that point because that opens the door into a wider discussion as to the real value of the data, if say a user creates a ST hubless account strictly to link his Arlo cameras into Hubitat. I would say such a small sample of data is useless to Samsung.
But the bottom line is that I've fixed the bug so users can enable HubConnect in a hubless ST environent.. However the my official position on this remains unchanged in that I must consider it to be an unsupported configuration.
I agree, to disagree. 
I posit that ST shut ArloPilot because the Vendor Relationship out weighed the monetization of the Data. Had it been generating them Income, they would have gone to bat over it, one presumes, telling Arlo to suck it up.
There is no positing required. That's exactly what happened. It took me almost a year to get an explanation and even more recently the internal ticket # discussing the issue.
Good discussion, albeit pretty off-topic of the original poster's question... I definitely share in the blame for that!
I believe that if anyone was going to complain about HubConnect's use of cloud services, it might actually be Hubitat. I speculate that Hubitat would want to keep their cloud endpoint services to a minimum to manage ongoing cost. HubConnect's use of the Hubitat cloud endpoint could be abused as well...
2 Likes
That’s already been brought up to me in the past. 
3 Likes
If Homebridge/hoobs was onboard do you think Homebridge to hubitat is possible?
Are you suggesting having HomeKit devices be shared with a Hubitat Hub? The reverse is already possible, as I am guessing you already know.
Yup, the reverse?
I believe that is an Apple restriction.
Apple's HomeKit doesn't offer that direction, as far as I know. Apple believes they are the center-of-the-universe and HomeKit is the center of control. HomeKit to anyone/thing else would be ceding control, I guess.
You can “sort of” do that for simple HomeKit devices...
Create a virtual switch in Hubitat, then share that to HomeKit via HomeBridge. Finally, create a HomeKit Automation that is triggered by a real HomeKit device and then turns on/off the Hubitat virtual switch.
Some use this technique to use HomeKit as an arrival sensor, for example.
3 Likes
