Despite their best efforts in this Matter, Apple, Google and Samsung remain the cat, dog and mouse of smart home. Not sure which one is which, though 
3 Likes
Dog's will love you unconditionally.... but cat's are popular in my group at work.... Hmmm.... And we work with Google more....
1 Like
When the dog will love the cat, and the cat will love the mouse, that will be the day when Google, Samsung and Apple will work seamlessly together. 
5 Likes
And Hubitat will work with Samsung, Apple and any other HA platform.... 
Hmmm... Sorry... That was perhaps a little harsh.... Hopefully taken tongue-in-cheek....
1 Like
That's the plan, why not? “United We Stand Divided We Fall,” right?
1 Like
Aye, Aye, Cap.... 
1 Like
Change that to "if all the apps were Python scripts" and you sort of have Home Assistant.
2 Likes
Highly unlikely. I had some X10 stuff set up back in the day, but it wasn't terribly reliable and never did much of anything with it except to turn a few lights on and off.
Used ST for a few years but got fed up with how unreliable it got and discovered HE ironically from some posts in the ST forums.
If someone came out with a hub that ran the .NET framework and allowed apps, drivers, rules, etc. to be written in a .NET-compatible language, I would definitely take a look.
2 Likes
Isn’t that what HomeSeer is? Not sure how open they are to community development.
How does that work on smartthings these days? I thought they were moving away from having custom code that can run in their environment? It's been a long time since I've followed what's going on in ST news.
The specific language used for custom code doesn't matter all that much to me, as long as there is something.
Wasn't aware of that, and they certainly don't seem to promote that fact. I had to dig around in their web site to see that they support Visual Basic (ugh) and C# scripts.
Interesting but despite what I said, I'm too invested into HE right now to even consider another platform. HE pretty much does what I need/want it to do. at least for now.
The SmartThings Edge driver framework allows drivers written in Lua to execute locally on the hub. But the implementation has several serious caveats. You don't get to see the source of the driver that is loaded onto your hub. Updates of the driver are pushed by the developer, and AFAIK you cannot prevent them from happening. It continues the model where someone else can change/update your automation platform without your control.
Oh, and people have reported performance problems when they had more than 20 Edge drivers installed on their hub.
Custom apps no longer exist in SmartThings. You need to have another host on your network (or in the cloud) to run custom code that talks to your hub via an API.
2 Likes
You can run whatever you want using the Lua environment/Edge framework with some caveats. The main one vs HE is that its sandboxed to communicate only on the local LAN (so no internet/cloud access). That forces any community based drivers to be 100% local. I've done LAN, Zigbee and Zwave custom drivers this way and it works fine.
This is true, although in practice I've not had too much issue with it and is more for community drivers than the official ones from ST. All of the ST drivers are open source (compare to HE which only a few example drivers are). Community driver providers are free to open source or not. Some of mine are open, some are not for various reasons. Its up to people to decide if you want something "opaque" on your hub or not. Now it is true you can't see whats actually running on your hub, you have to trust that the Github archive is what is running if it is open source. Not being able to control updates is true as well, but again this really is only an issue for community drivers that you don't control. For open source drivers you're free to put them on your own driver channel and control the update cycle that way. I've done that on my development hub and its fine.
This is true too. Edge is still in the tuning phase where limits are being reached and its unclear where they are yet. The tools to see the ram/flash usage of drivers aren't there (for end users anyway) so there is some uncertainty. The V2 hubs have double the ram/flash as the V3 (same as the current Aeotec hub) and all 3 of my hubs are V2's, so I've had zero issue with this supporting over 100 devices. Each firmware update has tweaked driver RAM usage and I'm sure there will be more progress with this. As a driver developer I do wish I could see resource usage in real world use so I could tweak my driver code accordingly.
2 Likes
You fare much better on the later model hubs my c4 had some issues as well it's now been fully retired.
It seem the issues with the C8 are users who migrated their database, for you that wouldn't be possible other than the apps database. So I would go for it.
Are your devices zigbee or z-wave or both?
Thanks. The HK integration has been pretty seamless. It's a great combo. My biggest quandaries are things like where to run automations, because I have two choices. (Well, for my Thread devices I have only one )
+1
Never stopped using ST it does some things better than HE. Same as HA. I have all 3 (plus some Aqara/Mi home hubs) linked together and that works well for me.
I am using Hubitat for all my z-wave and Zigbee devices now (after latest IKEA firmware updates).
And of course, for all my automations!
SmartThings - use the mobile app only, undoubtedly much better than HE. A small number of all my Hubitat paired devices (thermostats, temperature/humidity sensors, water leak sensors) are pushed to ST using Mira local integration)
Aqara E1 hub - for one Aqara Smoke detector (hopefully will manage to handle it locally from HE soon). And for sniffing Zigbee devices protocol when needed.
Apple Home Pod hub - for one single Thread T/H sensor and for testing.
Home assistant w/ Zigbee2MQTT and ZHA - for testing, also for bringing some Xiaomi WiFi devices to Hubitat.
Tuya Zigbee hubs - for sniffing the Tuya-specific Zigbee protocol (needed very rarely now) and making the devices work locally on Hubitat : )
I forgot the Philips Hue hub - a rock solid solution for controlling almost all of my lights, integrated to Hubitat via CoCoHue.
5 Likes
I still have ST running at another location with a few devices on it. I will eventually replace it with something else but it's working fine for now so no biggie.
1 Like
7 posts were split to a new topic: Off-topic debate
Just a reminder that this is a public place. While there are no hard rules to posting, we strongly encourage our users to be respectful of others and to refrain from personal attacks... We can all be agreeable, even when we disagree...
Be Agreeable, Even When You Disagree
You may wish to respond to something by disagreeing with it. That’s fine. But remember to criticize ideas, not people. Please avoid:
- Name-calling
- Ad hominem attacks
- Responding to a post’s tone instead of its actual content
- Knee-jerk contradiction
- Disparagement of others
Instead, provide reasoned counter-arguments that improve the conversation.
...more
8 Likes
1 Like
