I just became aware of Hubitat after 2 years of being a SmartThings user. So far I've been very impressed. The recent notice that SmartThings will no longer support Echo Speaks and the end of support for the classic app has me thinking of switching. But I have a couple of quick questions I was hoping someone could answer:
Does Echo Speaks work with Hubitat?
I currently use a webCore piston that monitors a Zooz Z-Wave ZEN15 Power Switch and executes above a certain power usage and then notifies me when the power usage drops back below another level (i.e. dryer is done). It also calculates the power used in kWH and reports that in the notification. Is this possible using the Rules Machine? I'm not looking for specifics now, only if it is possible.
From my research so far, I understand that webCore has been ported to Hubitat. Is this correct?
Does the Rules Machine support things like activation at sunset +/- a few minutes? Again, not looking for specifics now only if it is possible.
I have a Chamberlain garage door opener with a Chamberlain Smart Garage Hub that I can control with SmartThings via the MyQ lite smartapp by Brain Beaird. Then with the Alexa SmartThings skill I can tell Alexa to close the garage door. It looked like somebody tried to port MyQ lite. Is the port working?
Can the the Rules Machine do stuff like if button is pushed and light is on then turn off the light else turn on the light? I have two buttons that control one light and I currently do this with webCore.
Sorry for all the questions. I'm just trying to make sure I can achieve the crucial "wife acceptance" prior to purchasing. Thank you in advance for any help.
It's not like "Anything SmartThings can do, Hubitat can do..." (isn't there a song for that?)
But it's not very far from true. Hubitat uses Groovy too and most of the ST DTH have been ported over. There's a LOT of similarity. But there are differences too.
Most of what you ask is doable... the ONE I can't comment on is MyQ.
For SmartThings, there's tools to ease the transition. HubLink / Link to Hub were created for that purpose. You can leave devices on ST and just experiment with moving the Automations, for example. It works best for Switches, Dimmers and Outlets because of their simple list of Attributes. A community created App called HubConnect works with all Attributes and is mush more robust as a result.. it's also more steps.
Yes. Note, there is presently a bug with Sunrise/Sunset, but i expect it will be resolved in a hotfix shortly.
The MyQ lite port works fine. I added a monoprice Zwave tilt sensor which gives the app a bit more capability as to determining state, but otherwise it Works right out of the box!
(4) yes, using it. For many things, there is also the Simple Lighting app that can do a subset of RM with a simpler interface.
(5) yes, using it. You will need a contact sensor so that the MyQ Lite driver knows the door position status. Hubitat cannot access the Chamberlain position sensor because Chamberlain blocked that access. Many people, though, (not me) use a Z-Wave relay to actuate the door so that the Chamberlain cloud path is eliminated.
You should enjoy it. I was on SmartThings for two weeks until the implosion started earlier this year, then migrated to Hubitat. Community forum support is great. Welcome.
If you are an avid WebCore user this can make your initial transition much easier. Backup pistons to a file in ST WebCore, and them import them into Hubitat WebCore and update your device selections in your pistons. The biggest pain is pausing all your ST webcore pistons as you get them up and running on HE.
Doing that allows you to be up and running quickly, and then you can take time to look at Rule Machine and decide what you want to do in there rather than WebCore.
Also, WebCore pistons run locally in HE, so you get the local execution benefits that you don't get on WebCore on SmartThings. Piston creation is still cloud based in HE, unless you want to set up a local instance of WebCore on a Pi, etc.
And included your second question above, as if you're doing that in WebCore now, if you want to you can keep doing that in WebCore after you migrate to HE.
HE is a lot like, and in some areas a lot different than ST...plan ahead to take your time as you start migrating over and you'll be a happier camper.
Yes, and the author @tonesto7 has said he plans to keep working on it even after ST kills their support.
Yup.
Yes, but note that WebCORE was designed to run in the cloud on powerful servers, not on a small hub device. Some have reported that they experienced slowdowns running this on HE. YMMV.
Sure does.
I'm that somebody I do my best to keep it in sync with the ST port and I own a MyQ myself and use the app. It has the same limitation as the ST app, you need a sensor device on the door.
Most of the things you can do in WebCORE can be done in RM. The one thing that is hard to replicate is the "stays" functionality (e.g. door stays open for 5 minutes). It can be done but not quite as easy. Personally though I will say that WebCORE had a much more user friendly editor/IDE than RM. I find myself getting frustrated at all the dropdowns in RM to choose things instead of just being able to build the rules as simply in WebCORE.
There will be bumps. But what I can say is my wife loves that most things are super fast now. Open a door and the light turns on in milliseconds, not when you're halfway through the room already. I can say I've also been able to integrate many devices that would not be possible to integrate into ST so she loves that there is more stuff automated.
The current webcore runs as fast or faster than RM. this has been shown by several different folks.
I don't think for most typical applications you will find RM faster than webcore.
The current optimizations for HE use very little state, or db accesses, and the code has been optimized to run quickly on the HE hub. Typical small pistons can execute in < 25 ms.
To my knowledge Hubitats official stance is if you have issues and you have webcore installed they will tell you to remove it before providing support. Not saying I agree it will cause issues, but as far as I know that is still the official policy and something people should be aware of.
I saw a comment by staff (think it was Bruce ) saying that they don't have the issues they had in the past and it's not a issue anymore due to the work @nh.schottfam has done. This was no more than a week ago. Now it's just the same as all other apps, if you have a issue your need to disable them to remove them as the possible cause. But it's not longer actively discouraged or a known issue.
Wow! Thank you all for your incredibly helpful and fast responses. It seems what I read about the Hubitat community being great is very true.
My setup isn't really very impressive compared to what I've been reading about in the community. Only 40 devices (mostly zigbee smart bulbs and smart plugs) and only 10 webcore pistons, all with pretty simple code. Sounds like some of what I do with pistons could be moved to the RM. So it seems I'll be able to do all of what I want to do without taxing the Hubitat too much.
Side note: Be very proactive when you're considering your smart Bulbs. There are a lot of issues with Zigbee bulbs and building a good mesh, specifically when bulbs are attached direct to the Hubitat hub, and not on a Hue or other hub.
There are several threads on Zigbee meshes and Hubitat. Good Luck, and Welcome to the Community.
Thank you for your note. I had issues with the zigbee bulbs early with ST. I solved it by strategic placement of the zigbee smart plugs. Do you think if I have a working mesh now that it could be a problem with Hubitat?
You're going to be disassembling your existing Mesh and building a new one. There's little chance it will build exactly the same. You will be removing devices from the old mesh, eventually making it so unstable it's not working, while you build up the new... hopefully getting more and more stable with each new device.
If you want to have the best possible results I think you can get that by doing the whole changeover in one day. Begin with your powered devices closest to your hub and working out, and when you have all them in place then start adding the bulbs in the same order. If you try to do sort of a half and half parkway approach you may end up with weak meshes on both sides that can be annoying during the transition. I thought I was going to do some sort of gradual transition but I ended up doing it all in one day and I'm very happy I did it that way.
What I did do over a few days before that is move on my webcore pistons over and get them ready to be set up and enabled with the new devices when the new device is show up. That way once I moved over the devices, it was just a few minutes of work to get the devices selected in the desired pistons and my automations were up and running on HE.
Hubitat uses Groovy too and most of the ST DTH have been ported over. There's a LOT of similarity. But there are differences too.
I do my best to keep it in sync with the ST port and I own a MyQ myself and use the app. It has the same limitation as the ST app, you need a sensor device on the door.
) saying that they don't have the issues they had in the past and it's not a issue anymore due to the work 
Heck we don't have any officials...
