Alternative Hubs

I don’t have a lot of free time, been here with ST for years.

I’ve got smart zoned CH, hottub (smart, propane powered), alarm system, garage door opener, all the usual lights etc.

Slowly moving over to hubitat now, and wish I’d took the plunge years ago.

I’ve moved the essentials so far. Whilst I’m doing that I’ve just had my ST hub disconnected to be honest. So right now my CH doesn’t work (don’t need it), but I think I’ll struggle to get the TRV drivers to work under hubitat (I’m relying on @GSzabados to potentially port the driver which works under ST, but if not, I’ll probably leave this part running with Samsung until I replace the trvs with some simpler solenoids - then move to hubitat). If the driver can be ported, it’ll save some cash and hassle!

For me, smartthings has became a piece of crap. Awful.

Hubitat so far has been a breath of fresh air.

5 Likes

That guy is a f#cking clown shoe. (Just to use a quote from a movie…)

Look at the current concept of ST. As far as I can understand, they are going to shut down the whole IDE and they will not host any of the current SmartApps anymore. You have to sort it out by yourself some way. Either on a cloud service or on a device what you host, but still relying on some sort of cloud provider to make the route to your device (ie.: ngrok). Nobody is talking about local access, just cloud. ST puts all the security stuff of access control of SmartApps in your hand. Sort it out by yourself, they provide the API.

Meanwhile HA does everything by itself. You don’t need to worry about access control as Nabu Casa provides it for a small monthly fee. Of course you can do it by yourself, but it is more convenient through Nabu Casa.
The number of integrations is quite high, the developer community has a decent momentum. You can share load between HA devices, like setting up satellite devices for sheds etc. And you really need a single device to have all sort of integrations, automations, etc running. The Lovelace UI is far more flexible that the current SmartThings app’s UI (without full documentation and limited use options currently).
Of course, it is different from ST, far more complex. It is more for power users, but if you learn it, it can do more than what you think of it now.
And of course the firmware updates are documented well. Breaking changes is an amazing thing as documented. Just imagine if the Zwave issue with the endpoints would have been documented for the users when ST released that firmware a few months ago. A lot of firefighting could have been avoided.

And setting up on a RPi takes less than one hour.

Just saying…

… But you need to pay a monthly subscription for using voice assistants.

That is not true. You can do it by yourself. Look at the manual setup. Nabu Casa is not mandatory, but more convenient. The money spent for the subscription spent on running the cloud infrastructure and paying some services, plus for the further development of HA.

Not every company has a huge conglomerate behind it like ST. And at the end you bought a device and services are slowly removed one by one. That is how Samsung operates.

3 Likes

I have migrated to the new app. Certainly not what I would call a smooth migration. I don’t think that I’m a power user by any stretch of imagination,but I was able to clean up most of the mess and tweak some of the migration conversions. I mostly access SmartThings via Alexa, to initiate STHM, and with virtual switches (momentary), actual physical contact switches, and physical motion device to have Alexa “voice” that some type of activity occurring.

As far as using Alexa to control STHM It’s working OK. My process, as well as probably others have probably used is as follows:

  • Alexa, Turn on security
    Executes an Alexa routine, that has an action to set on a scene in ST that turns on a virtual security,
    switch, Alexa then follows up with another action to announces that “security is enabled“. (Yes I’m
    making the announcement “assuming” that the ST side will execute and work properly.)
  • ST then executes the specified scene that sets the virtual switch, and initiates an “automation” that
    sets the alarm status to away, and then the automation initiates another scene, that sets lamps,
    lights, etc, and sets the hub mode accordingly.

So far, this is working without any issues. I think because the actual switch setting and subsequent processing all occurs on the ST platform.

What doesn’t work consistently is using either a physical device or a virtual device to trigger an event on Alexa. As I think most of us recognize, it works “sometimes” at best, and yes, @Lars has acknowledged that ST is having issues.

My question is for those with Hubitat experience, is that functionality, (triggering Alexa by physical or virtual switches), reliable and simple.

Thanks
TG

1 Like

Yes. I have not had any issues using a physical/virtual motion or contact sensor as a trigger for an Alexa Routine. Switches cannot be used a trigger (unless you’re using a special virtual switch that also implements a contact sensor capability as well :wink: )

3 Likes

Thank you for your reply.

I am/was using both physical and a virtual momentary/contact switch (bjpierron code) and think that can be ported over.

I haven’t fully decided what I’m going to do yet, but Hubitat will be my first choice if I leave the ST platform.

I’m truly hoping that ST gets their act together in the next few days, and is able to resolve the pending issues. Like I said, I don’t consider what I do to be a power user and for the last 4 years have intentionally tried to stay away from custom code and run a more or less vanilla setup. I’ve pretty much stuck to that methodology and that seems to be failing now.

TG

1 Like

Sure, I got it setup on a Linux computer in a docker container in less than an hour. Trying to get it to do anything else and connect to things? Better have a lot of time on your hands.

Don’t want to pay a monthly subscription fee? Hope you are very comfortable with port forwarding rules, obtaining an Amazon developer account, setting up a dynamic DNS server, and exposing your router to the internet.

That being said, it has a lot of potential, and I’ll continue trying to use it. I think a lot of people have gradually switched things over when they first get HomeAssistant. I haven’t been thrilled with the way this Smartthings transition is working, but have worked through it. I just bought this thing a few months ago. Given the chance for a do-over, I would have bought a Hubitat, but don’t want to shell out another $130 right after buying my V3 Smartthings hub.

At least Samsung isn’t saying “pay us in 7 days or we’ll brick your hub”. Who knows what will replace the IDE or what the future holds. If it sucks at that point, I’ll be investing the time in Home Assistant. But right now, I just don’t have the time to set everything I have up on another device.

2 Likes

The frustrating thing is ST would have a rock solid industry leading product if they could just strive to do a few things right…

  1. Don’t break things in the name of modernization.

  2. Run what you can locally. Especially STHM, automations, and app connections when on network.

  3. Have a transparent and well communicated roadmap and register of caveats.

1 Like

Hue, Lifx, Sonos, all Google Home devices connect in a few minutes, plus more what it can find on the network.
Setting up a Zigbee2MQTT dongle takes some time, but adding devices is the same easy. If MQTT then Tasmota devices works as well quite quickly.

Two things what I forgot to mention. First, the Lovelace UI makes that you don’t need ActionTiles or Sharptools.io (sorry guys) to make any special panels.
Second, there is a SmartThings integration as well so moving things can be done gradually. Again, it works well with the Nabu Casa subscription.

Yup, I took over Hue B Smart which I have removed from my ST and is how running CoCoHue on HE, My Life360 with extra’s and a few other things I took over or made will no longer be supported by me.

1 Like

Absolutely. And you know what the most frustrating thing is? The replacement is not ready for prime time, and the old app is getting phased out before the new app is fully functional. The developer thread on the custom CLI and VID is a train wreck of problems with developers trying to figure out how to get their apps and dth’s to work in the new app. The CLI is still in Alpha release. How can you phase out the old app when the tools necessary to write replacement code for the new one are still not even working? That needs to be fully up and running, and then developers need a sufficient amount of time to rewrite their code before replacing anything.

Instead its, oh crap, we’re running out of server capacity, so lets just flick the switch and hope for the best.

7 Likes

Yep I’m bailing to hubitat. Got one location mostly moved. But issues with zwave in new hub causing problems . But easily Ported all my device types and apps .

mwav3 Tim
August 28

swamplynx:

Don’t break things in the name of modernization.

Absolutely. And you know what the most frustrating thing is? The replacement is not ready for prime time, and the old app is getting phased out before the new app is fully functional. The developer thread on the custom CLI and VID is a train wreck of problems with developers trying to figure out how to get their apps and dth’s to work in the new app. The CLI is still in Alpha release. How can you phase out the old app when the tools necessary to write replacement code for the new one are still not even working? That needs to be fully up and running, and then developers need a sufficient amount of time to rewrite their code before replacing anything.

Instead its, oh crap, we’re running out of server capacity, so lets just flick the switch and hope for the best.

6 Likes

Is it possible to migrate exsiting webcore pistons and/or grovy smartapps to Hubitat?

Yes and Yes.

2 Likes

I know I agree with this statement, as do so many users here.

However, SmartThings and Samsung think the new app is not only fully functional but also a suitable replacement for the Classic app. This massive disconnect is what made me begin my transition to Hubitat.

7 Likes

I sometimes wonder if they want power users to leave. Samsung employees have made statements along the lines of “this small percent of users use a huge percent of the resources” when it comes to getting rid of Echo speaks.

At a company I worked for once, when we had difficult clients stuck in a contract that we had to deal with, sometimes we would call them and actually try and aggravate them on purpose so they would cancel, so it wouldn’t surprise me if some of that was going on.

4 Likes

I agree with the sentiment and I appreciate all of your past contributions @Lgkahn and in an ideal world we would have done it this way. We are working to improve the developer experience with with the CLI, and we are doing it out in the open with community developers. Given the complexity of the migration there was no way to simply do it all behind closed doors until it was perfect. Developing two apps/platforms has been a drain on resources. This sunset will allow us to focus on getting the user experience right in one spot.

1 Like

thanks i dont have hard feelings and maybe someday will come back , the kicker is the issue with all the groovy code going away or having to be hosted somewhere. I have quite a few custome device types and smartapps that i dont want to rewrite in java c++ etc. or host myself… although that last option is a possiblity but it seems there are tons of hoops to go through to host it yourself. although that is not fleshed out…

Also I dont believe the new app has the same functionality as the old. I understand it is for streamlining supoort but the details available for each device are very limited… and if you have a lot of rules or devices half the time the page takes forever or never comes up…

4 Likes