Hubitat ST Integration

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.

1 Like

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. :slight_smile:


@ 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 :smiley:

@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.