Do note that even if you get HubConnect working now, the future of the SmartThings side of things is quite unclear--or rather quite clear, just with nebulous timing, as it will stop working whenever it is that Samsung decides to shut down the "classic" Groovy IDE, which has been in the works for years now. I believe it does still work, but I haven't used it in a couple years at least. (Someone could theoretically re-write this for their new API, but I wouldn't count on it...)
But in the meantime, I agree with the above--your issue is likely related to the updated color temperature capability commands in Hubitat, the same issue you found with community drivers and Rule/Button Rule 5.x. For the most part, HubConnect just passes commands and parameters as-is between Hubitat and ST since the device model is so similar. If you use the new multi-parameter setColorTemperature() command, this will fail on the SmartThings side. Options to fix it include modifying the real ST DTH, if this is a SmartThings device shared to Hubitat, to accept the multi-parameter version; modifying HubConnect to intercept and "translate" this command specifically into separate commands on the ST side if needed (separate setColorTemperature() and setLevel() calls, ultimately); or using custom actions in your Rule apps on Hubitat to call setColorTemperature() manually with just one parameter, rather than relying on the built-in rule actions that may use the multi-parameter variety.
Sorry if I offended. I thought with Steve heading to a new platform this app was basically in a use as is state. As far as I know, no one has chosen to pick up the reigns yet. You are doing a great job keeping it going @csteele though.
Awesome, thank you for all that explanation. I was trying to figure out how smartthings received the commands. Didn't occur to me it was just straight from hubitat.
I was able to modify the "HubConnect RGBW Bulb" driver on the hubitat side to split out to a separate setLevel() and now it works, for the most part.
I guess I should plan to remove smartthings once and for all (Only started using it again because of the availability of hubconnect and the issues I seemed to be having with these particular bulbs), or maybe finally retire these bulbs. Is a second hubitat hub recommended? I might just go that route.
@csteele ...I agree with @mavrrick58 that you are doing a great job keeping it going.
I have a dedicated C7 hub running Envisalink for my Vista 20 alarm panel. The native Envisalink uses telnet and is very chatty....therefore the dedicated hub. I could have used a Raspberry Pi but it was easier for me to set up a dedicated hub. The dedicated hub is linked to my main C7 via HubConnect. It works because HubConnect allows me to synchronize HSM between the 2 hubs. Not sure if Hub Mesh will do this.
So thank you @csteele for keeping HubConnect working!
It's just an alternate method of installing. Result is the same.. the code that is needed land in the correct spots (Apps Code or Driver Code)
v2.0 is exactly the same as v2.0Beta2 with every file touched to remove the Beta aspect.
The question of ST and the future.. has been answered several times in this topic.
There is no future as far as I can tell. If/when ST pulls the Groovy IDE, that impact will be what ST dictates. Will pulling the IDE be a "can't make changes" but it will continue to work? And if so, how long?
All of that are ST questions and I have no insight.
Is there a way to have Life360 presence sensors linked in smartthings?
I have a few devices that won't show in smartthings for some reason. I was able to create virtual devices for some of them and then link the status to the actual hubitat device.
I'm just mirroring devices from hubitat to smartthings since that is the app my wife already knows.
@maverik which specialized driver do you mean? Can you also use it for a Samsung washer to get the current status? The other possibility would be the power monitoring as mentioned by @markbellkosel84 .
Sorry if this has been answered but I wasn't able to find it. What will happen to the hubconnect devices that are in Smartthings and Hubitat? Will they just disappear on September 30th or will they show up as ghost nodes that need to be cleaned up?
Whatever is the most inconvenient for their customers, I presume. The remote hub will appear unresponsive, because of course, without Groovy, it can't respond. I'm expecting I'll have to delete the remote hub instance.
I've been trying to end my SmartThings interaction for 3 years
Twice I've shut down SmartThings, only to be pulled back via the Community... once when Steve created HubConnect and I volunteered to assist with the support. After ST announced its pull back from Groovy and Hubitat released HubMesh, I shut it down again. I was pulled back in by new ST migrators and had a Hubless instance running for a year or so.
Today, I ended ST for the 3rd time and shut my Hubless instance. I've removed everything from the ST App, and then removed everything from the IDE.. Apps, Drivers and Devices.
I carefully place this burden into it's small box, seal it with tape and slide it onto the shelf.
If/when ST pulls the Groovy IDE, that impact will be what ST dictates. Will pulling the IDE be a "can't make changes" but it will continue to work? And if so, how long?
