Continuing the discussion from Hubitat⢠SmartThings Integration:
New to Hubitat. Does 'one way' mean that we will not be able to control these virtual devices from Hubitat? I followed the instruction and all of my devices show up in Hubitat but I can't seem to control a light on/off from Hubitat although the state changes if I trigger the switch physically or from ST. Just checking that this is expected behavior.
The intent here is that when something happens to the device in ST, the shadow device in Hubitat does the same thing. So if you have a motion sensor in ST, you could have a rule or an app in Hubitat that responds to motion events on that motion sensor. With this integration, nothing that you do in Hubitat will affect anything in ST. It is one-way, ST ==> Hubitat.
I think I understand that part but should a virtual switch in Hubitat be able to actually control a physical switch on and off? Thatâs the part Iâm not able to get working but wanted to understand âone wayâ before I started digging deeper.
Example: From Device list / Kitchen Lights, the On and Off buttons do not control the lights
So here is what I did. I moved everything over to hubitat and installed this:
Then if there were features in ST that I wanted to use I controlled the virtual devices in ST which then updated the devices in Hubitat.
Can you explain a little more what you're trying to accomplish?
A virtual switch in Hubitat, that is created by the 'Hubitat ST Integration', is essentially READ ONLY from the Hubitat side of things. If you change that virtual switch from Hubitat, nothing will happen in ST. This is what is meant by one-way. ST -> Hubitat only.
Note: The Other Hub SmartThings Integration 2.0 integration from @krlaframboise, is a different tool altogether. It is a Hubitat devices to ST integration and is bi-drectional. Hubitat <-> ST. This means that real Hubitat devices will be also created as virtual ST devices. The big difference is that you can change one of these virtual Switches within ST and it will actually cause the real Hubitat device to also change.
At this point just testing but ultimately porting 134 devices from ST to Hubitat is my goal.
I registered my Hubitat today and ran the ST -> Hubitat integrations and then tried to control a switch from Hubitat. It didnât turn on or off via Hubiatat.
If the Vswitch in Hubitat is READ ONLY and unable to actually control anything in the house, what exactly is the purpose of the Hubitat/ST Integration? Perhaps just to get a pre-populated list of devices already in ST?
I expected that with this simple integration I would be able to control a physical switch from ST, Hubitat or by touching it. No?
The idea is that for devices (primarily sensors) that you only have drivers for in ST, you can get a âreflected copyâ available in Hubitat.
For example, I have Ring Doorbell that has ST integration. It shows up in ST as a Motion Detector (a sensor device). I use the âHubitat ST Integrationâ to create and keep an updated copy of this motion detector in Hubitat. I then use this copy in various rules and automations to trigger turning outside lights in the middle of the night. The lights the RM Rule activates, are all devices that I have already moved over to Hubitat.
Make sense?
I agree, ideally two-way would be nice. But it could also get very confusing, very quickly.
I really wanted this to be bidirectional too. There are some devices you just canât transfer to Hubitat currently, particularly any that are cloud service based. To be able to use these from Hubitat would be a big plus I feel to migration.
You can kludge it by using Kevinâs other hub app and then linking the virtual device in ST to the real ST device you want to control but itâs messy.
Please consider implementing this Hubitat.
Thank you for this.
So with a new Hubitat hub and only the Hubitat ST integration loaded and working, I cannot actually control anything in my house from Hubitat until I remove the device from ST and then add it to Hubitat as a real device?
I was hoping that this integration would allow me to control a light switch from either ST or Hubitat while I get things migrated. I think I misunderstood the intent of the integration.
Yeah, itâs unfortunate that the built-in integration is one way (ST to Hubitat, read-only). But it works well for sensors, like motion sensors, door/window sensors, temperature/humidity sensors, etc. These are devices you would only want to read anyway. It does not work well for things like lights or switches, which you might also want to control from Hubtiat.
The âOther Hubâ app/DTH from krlaframboise mentioned above gets you Hubitat to ST integration, with more or less bidirectional syncing (though only capabilities you choose are synced in real-timeâI chose âswitchâ and âmotionâ since thatâs mostly what I care about; others get synced on a schedule). The downside is that the device has to be paired with Hubitat.
There are advantages and disadvantages to both methods. If you have the time to re-pair devices from ST to Hubitat, the community âOther Hubâ integration is, in my opinion, the better option. First, your devices are actually on Hubitat so you get local control, but you can still keep your ST automations by replacing the ârealâ device with the âvirtualâ one from this integration (which, unfortunately, also means youâll have to go into each ST automation and re-select the device in each affected automation). Second, you get bidirectional sync, so you can immediately start creating logic in Hubitat or keep using it in ST, and it will work the same (after, again, swapping the virtual for physical device). Hubitatâs native ST-to-Hubitat integration has the advantage you donât need to re-pair devices, but it requires the ST cloud, and you arenât able to control devices in ST, so youâll really need to have affected devices paired with Hubitat anyway if you plan to control them (and in that case, Other Hub will still let you keep logic and whatnot in ST).
Thereâs also no reason you canât do both: keep sensors on ST, and move any devices you want to control (lights or switches?) to Hubitat. (But speaking of lights, Hue integration is something they are still working on.) Then, as time permits, you can also move your sensors to Hubitat and use only Other Hubâand, if we all become so fortunateâmaybe move off ST entirely some day. 
@ bertabcd1234 great explanation!
Iâll probably just start from a clean slate and slowly remove devices from ST and add them to Hubitat as theyâre supported.
I have ST Multi Sensors, Aeon Multi 6 sensors, GE/Jasco Zwave and Zigbee dimmers GE/Jasco switches, ST outlets, OSRAM Lightify led strips, Nest tstat and protects, Yale zwave deadbolts and a Rachio irrigation system. Iâm also using various IFTTT triggers for a GE Hybrid water heater. Itâs all tied together with HomePods and Homebridge for voice control.
I know some of this might not yet be compatible so Iâll start simple in the beginning 
@bravenel do you have any plans to make the ST integration bidirectional? Maybe at least for certain types of devices like ones not 100% supported in HE yet? My request is to make locks bi-directional given there isnât an app yet to manage codes. I attempted to move a lock to HE but had to move it back since I couldnât manage the codes like I needed to. I currently use Rboyâs lock manager app in ST.
Ideally it would be great to be able to lock this lock via Hubitat rule every evening.
I also have thermostats in ST that arenât supported in HE yet too that would be great to control. In my setup the control is simple and something I will be attempting to port over.
No. This is not where we will put our resources. We'd rather put our resources towards (a) developing a lock code manager, and (b) supporting more thermostats -- both in the works.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
