A Hubitat application to allow real-time bi-direction updates between Hubitat and SmartThings devices, modes, scenes, weather and push notifications utilizing the SmartThings OAuth Cloud API. Includes the ability to have multiple ST locations with multiple ST hubs replicated to a single Hubitat hub. It is not a requirement to have a ST hub to operate mirror functions to cloud native ST devices.
This solution requires a reasonable degree of understanding of both Hubitat and SmartThings. The original design was to mirror the few devices I have remaining in SmartThings to Hubitat in a real time fashion, but grew into a full project thanks to @Alwas, @bthrock, @hendrec, @swade, and @hendo25.
One primary use is to allow ST webCoRE users to continue enjoying that application operating on Hubitat. Please note, this is NOT a replacement for HubConnect and doesn't operate the same. Obvious shout out to both incredible products.
The HubiThings Replica application collects the capabilities of the ST device and stores the information in the HE device data section. Then using 'rules' to define commands and attributes from both the ST device and HE device establishes mirror functions. The HubiThings OAuth application drives real-time communication between ST and HE and issues those events to Replica. There are native Replica devices handlers and they auto-configure 'rules' for you - suggest you use them.
There are two required applications and many and growing native Replica device handlers (not required but advised).
You can install using Hubitat Package Manager (HPM) with fast keyword search 'replica' or manually as per below.
HubiThings Replica (Install first):
HubiThings OAuth (Install second):
Replica Device Handlers:
Base Library: https://github.com/bloodtick/Hubitat/tree/main/hubiThingsReplica
- Install from the "Add User App" section "HubiThings Replica".
- Replica will prompt you to close after install and then reopen.
- Supply a full credited SmartThings PAT which will then allow the OAuth application to be accessed.
- Follow the prompt and install a HubiThings OAuth (it is a child app).
- Continue to follow the OAuth prompts and when successful you are able to pick ST devices to mirror.
- Return back to the Replica app and you should see the device(s) in the 'HubiThings Device List'.
- Click 'Configure HubiThings Devices' and follow the creation process. (Start easy with a simple ST device and use a Replica DH).
- If #7 was a Replica DH, the rules and device will auto configure and you are ready, if you pick a Virtual device, you will now need to go to "Configure HubiThings Rules" and match attributes to commands.
Note: Please be patient with questions and hopefully the team who participated in the Alpha can help you as needed. I am looking forward to what others can help bring to this project - it was designed for collaboration.
Older Release Links
- Update 2022/12/21: See this post to allow for bi-directional 'mode' replication between ST and HE.
- Update 2022/12/24: Beta release 1.2.05. Change log here.
- Update 2022/01/01: Happy New Year. First OCF driver posted.
- Update 2023/01/06: Beta release 1.2.09. Change log here.
- Update 2023/01/07: Beta release 1.2.10. Change log here.
- Update 2023/01/13: Release 1.3.00. Change log here.
- Update 2023/01/17: Release 1.3.00. Added to HPM. For existing installs see here.
- Update 2023/01/29: Release 1.3.02. Change log here.
- Update 2023/02/10: Release 1.3.03. Change log here.
- Update 2023/02/19: Release 1.3.05. Change log here.
- Update 2023/02/26: Release 1.3.06. Change log here.
- Update 2023/03/14: Release 1.3.07. Change log here.
- Update 2023/04/23: Release 1.3.08. Change log here.
- Update 2023/06/05: Release 1.3.09. Change log here.
- Update 2023/06/17: Release 1.3.10. Change log here.
- Update 2023/07/05: Release 1.3.11. Change log here.
- Update 2023/08/06: Release 1.3.12. Change log here.
Replica Device Handlers by Dave:
@djgutheinz has developed specialized device handlers with advanced logic for Hubitat Replica.
Included as of 2023-04-23:
Note: Samsung Oven and Refrigerator requires a parent and child(en) drivers. The parent will build its required child(en) automagically.
Install these drivers into the 'Drivers code' area of HE and then use Hubitat Replica to build the HE device to replicate with ST.
Please review the readme page for specialized setup configurations. These are also available in HPM.
Reserved for future use #2.
As an Alpha Tester, it was a privilege to go on this journey with you. This is truly well done, a professional effort at every level, and I'm excited to see it shared with the community at large at last in BETA form.
With this post, I'm also reserving space for future use as the BETA progresses.
I also had the privilege of taking part in testing this app and I support @bthrock's remarks 100%. It is a fantastic solution and I'm sure many Smartthings owners have been waiting for this to make the move to HE painless - especially for those heavily invested in webCore. The app makes it possible to integrate the ST and HE hubs and I'm sure many owners will in the end keep their Smartthings hubs running alongside the HE hub because of this app.
Does this require a ST hub?
I do not have a ST hub but I do have some devices that are using the ST cloud (Samsung VRF system).
I am currently using node red to connect the Samsung cloud to Hubitat using Maker API.
Can your app replace this method?
Good question, I'd say you're good to go. The code resides on the Hubitat hub and connects to the SmartThings API, which is in the cloud, I see no neccesity for a ST hub.
Hubitat Replica uses the SmartThings API to connect to and control devices from Hubitat, so you shouldn't have any issue with your devices. The OAuth child app will also allow you to subscribe to your hub(s), if you have any, for Mode control and mirroring, Device Health, Device Lifecycle, and (in the near future) Scene lifecycle.
There is no reason you should encounter an error if you don't have a hub, but I've always tested with a hub. If by any chance it does, @Bloodtick_Jones can address that upon his return from the holidays. He's quick and meticulous with fixes.
Given your current setup and experience, I expect it would only take you a few minutes to get this up and running and start adding devices. It won't affect anything on SmartThings or Hubitat until you configure devices, and can be easily removed if it's not for you.
Give it a spin, and let me know if I can help!
WOW guys, you are amazing!!!
I can now confirm that no physical hub is required.
All of my cloud ST devices are available and the integration seems to be executing very quick.
My issue now is that the device I am trying to duplicate is a Samsung HVAC unit (Samsung uses the name- Samsung OCF Air Conditioner) and I could not find the correct virtual device to emulate all its capabilities. For example when using node red I crated a virtual thermostat along with a virtual switch to emulate the basic capabilities of Samsung HVAC unit.
The list of Samsung capabilities is exposed by this app as:
Any idea how can get as many of these transferred into HE as a virtual device?
I'm curious: How did you find the setup process?
Although I'm not familiar with the Samsung OCF Air Conditioner and there is no specific Replica driver for that device (or thermostats in general) as yet, you can use Hubitat's Virtual Thermostat driver as per the graphic you posted.
The Air Conditioner's capabilities are all available to the app, but for rule creation you'll be limited by what's available in the Hubitat driver. Also, not being a Replica Driver, you will need to create the rules manually. Here, as an example, are the rules I use on my own thermostats.
The possibility of a Replica Driver for the Samsung AC has been discussed, but we'll have to leave that for @Bloodtick_Jones to look at after the holidays.
We do anticipate more drivers being created, with the hope that the community will pitch in. I've tried my hand at one so far, the Replica Motion Sensing Doorbell (for Ring), but the AC is above my pay grade as yet.
It took me a few tries. For a reason I can not explain, the ST devices took some time and tries to show up. I think the instruction are OK for a n experience user but it might be nice to add some screen shots in the GitHub repository for less experienced users.
All in all this a a job well done.
As for the virtual driver I am missing, I remember ST used to have a template to make it easier for users to create Device Handlers according to device capabilities. But I am not sure this is within my basic skills.
Driver creation is a topic of discussion. What direction it will take, I can't say as yet as that's not up to me.
First - great stuff!
I have a working shade (open close), but when I try to set it to 50% the command fails
This is older Somfy zwave RTS gateway on ST. It supports open, close and its one preset/programmed position.
There is debug in the advance section to watch the actual command sending to SmartThings. Turn that on and check to see what is going on. That error is ST not liking the the value getting sent to them. It is really finicky.
I guess also look to see if that command exists in your ST capability itself. The rule just gets jammed in when you build the device, so there might be exceptions that get washed. Look in the configuration section and you can see exactly what the ST device is capable.
"SetShadeLevel" should be in there.
Not sure if anyone uncovered this yet, but if you build a "Replica SmartThings Hub" device with your hub(s). You can follow/push ST modes and give you health of the OAauths in an attribute of that location. It was the 'weird' workaround to be able to allow multiple locations in the same Replica App.
I do allow creation and deletion of ST modes since the only way today was from the ST Groovy IDE, which we all know is about to go away.
I do have (it did it automatically) the shadeLevel
I guess I need to figure out if ST changed something, they did update my drivers during this process.
The rule list might not be telling the truth. Check the drop down " Then ACTION SmartThings Command:" and ensure the command is listed there. That is your real source of truth of the device capabilities. I pull that from ST directly.
The rule was based upon the shade we worked with during Alpha. And 'could' be incorrect for your device.
So here is what I see.
The ST device does not have setShadeLevel or setPosition, but it does have setLevel
note this is a custom driver in ST, as they have not migrated to their own. It is interesting they marked this driver to run local
The HE replica driver does not seem to have setLevel
I also cannot seem to override the
to force it to use setLevel
wow. they are using switchLevel (like a dimmer) and not the actual shade capability. I am remote at the moment, but given your skill level, take a look at the Replica dimmer and the Shade handler and you should be able to figure out the switchLevel command. this would be really custom.
The only secret is after you modify a Replica driver, you need to hit the config button either in the App config page or the device page itself.
Another way would to delete the command using the 'just the shade' and empty in the action (should allow the rule delete). Then build a new rule using the
Trigger HE attribute: shadeLevel* -> Comand ST Command setLevel
The application really doesn't care what you are doing, so you can get clever with it.
So I did option 2, and that worked. no code changes.