Oh, it's because the system doesn't "trust" you, yet. Your account is still new, but there is an easy fix to get past that. Join the Owners group and your trust level is updated instantly. Eventually, you'll gain a higher trust level as you read more posts and browse other threads.
To join the Owners group go to this page:
Working in IT Iām used to see āuser storiesā to create value streams etc. So, I thought I write my own āuser storyā about migration from Smartthings to Hubitat.
Iām writing this hoping it will find itās way to someone at the developing team of Hubitat and for anyone else who might be interested to read about the switch from SmartThings (ST) Hubitat (HE).
Iāve been using ST for about 5 years and had about 130 devices (mix of Z-wave, Zigbee and some WiFi). I started with internal ST app to setup automations but soon found that it did not have the complexity I was looking for, so I moved to Webcore and have been using it ever since.
I have not been very active in forums or looking at news for the last years as everything was running smoothly so you can imagine my surprise when I received the mail from ST saying, āwe will destroy everything you build in ST starting 15th of Octoberā (at least they gave me a month heads-up!).
Once I stopped running around with my arms stretched over my head and the panic stopped, I ordered Z-wave and Zigbee dongles for my Raspberry PI 4 (RPi) and said to my self āwell itās time to move to Home Assistant (HA)ā. Once I setup the RPi with HA and did my first simple automation. I soon realized I was not smart enough to do complex automations in HA (the fall was high, and landing was hard) as Iām not a developer or at least it would take A LOT of time to learn. With tears in my eyes googled the internet and found Hubitat, I had heard about this product but as my ST setup was running fine, I never explored it before.
As I was sitting at home clapping my hands like a child on Christmas wating for my HE to arrive and reading up on how to migrate from ST to HE, thinking to myself āthis will be even better then STā but unfortunately here is where it takes a turn for the worse.
Starting with the setup of HE, easy enough following the next, next finish all good so far. I then decided to move the HE from my DHCP range to a fixed IP. I changed the IP setting in HE and my router. After two days of troubleshooting and a couple software resets on HE I decided to let it have the initial IP and make that static (in the middle of my DHCP range), and said to my self āI will fix that laterā donāt get me wrong, I have been working as an IT technician since 1995 so I know my way around IT stuff (hence my interest in smart home appliance) but I moved on.
Letās migrate my devices, it will be fun they said! (or?), I hade no problems with Zigbee but Z-wave is a different story. I was used to ST where I could from anywhere in the house add/remove Z-wave devices. This is not the case with HE as I learned after a couple of hours of trying, but with a 10-meter TP-cable and some swearing I mange to get some Z-wave devices migrated, however some devices (mostly Fibaro) would not migrate. Tested to put them back in to ST and sure enough without any hassle it was back in ST. So, I bought a coupe of new Qubino devices to replace the ābad onceā, but with them I hade to work an average of about 30 minutes each to get them installed. Still I was in a pretty good mood as this is a one time job (I thought) as I have NEVER lost a Z-wave device in ST, some times I had to reconnect Zigbee devices but never Z-waveā¦..until now. However, itās been stable now for a couple of days āso cross my fingersā.
Ok so I got all my devices in to HE except Ring.com devices and a couple of other devices like some Ikea devices that I read a BS article about that it was not possible because bla bla blaā¦..but they worked flawless in ST (I wonder how that could be???) any how after spending a small fortune to replace ānot workingā devices it was time for Webcore migration.
Yet another article saying āhey is so easy and fun, just duplicate your pistons from ST to HE ā (made the name up as I donāt want to point any fingers) easy enough right! After duplicating almost all pistons HE became unresponsive, could not even get a ārestore backupā on it. Again āSoftware resetā and restore!? Or notā¦. Now the database was corrupt. To make a long story short I ended up at āStarting with the setupā (see above) meaning I was back at square one minus IP problem as I skip that part this time.
One week later!
Now, I was considering that the HE was broken (still do) but I needed to narrow down the problem. I found that Webcore was the villain. It looks as you canāt just duplicate pistons with complexity to HE at least not what I experience. So, I had to rewrite everything in Webcore, at least I could use old automations as blueprints.
Finally, everything was in place and my life could go back to normalā¦.mmmā¦noā¦not realy!!!
This is where phase 2 starts. I call it āSometimesā
Sometimes aka random. This happens when I run automations in Webcore, sometimes it runs ok. Sometimes it runs ok and still dose not do what itās told to do, even though it reports to have done it.
For example: I have a simple automation that turns on/off lights outside at different times. Turns on the lights in the afternoon 30 min to sunset, off at 01:30, on at 06:00 if not after sunrise and of again 30 past sunrises. Some days it runs flawlessly and sometimes it skips one or two triggers, but it doesnāt really skip the triggers it actuality skips the action of the trigger as I can see in the automation that it has triggered. It just thought it was not important to do the action this time around. Even the logs in HE says it has turned on/off lights and sometimes the device is āstatusā on or off even through is the opposite. This can be explained in some cases as it sometimes turns on lights with light level 0% without any reason but in this case it a switch without ālevel settingā. Should also mention that these are controlled by native device handlers (DH) from HE. I thought this could be a Webcore problem, so I then created rules in āBasic rulesā same problem there! WTā¦!?
A workaround that Iām testing now is to crate automations with a setting ārepeat loopā until condition is met, but this is something you donāt want to use unless you must as it can cause other problems.
Conclusion:
Anyone who feels offended don't! You donāt have to stand up for HE, as most people probably did not experience any of these problems, these are MY conclusions. Iām not mad or angry at Hubitat it wasnāt they who put me in this situation it was Smartthings, but I wonāt write what I think about themā¦. I still have a lot to learn about the Hubitat but as Iām stuck in āSometimesā phase troubleshooting I donāt get around to the discovery phase.
Smartthings pros and cons
Super reliable
Easy to get started with simple automations
Easy to include devices
Set it and forget it
Its cloud based
Company is controlled by idiots
Is not useable anymore
Hubitat pros and cons
Itās locally based
Easy to get started with simple automations
Itās unreliable
Could not find any support except forums and HW support
Difficult to add Z-wave devices
Can āsometimesā take seconds for lights to turn on
No indication if a device is offline (or hub)
If I could have a which list to Hubitat it would be:
Have a native app to check devises on/offline status. This is crucial as many have heating systems and burglar alarms connected (me include) that canāt be offline. Yes I know there are apps that dose this but not to 100% and this should be native.
Native support for big brands like Nest, Ring, Arlo, etc.
A XXL optional Hubitat hardware with 10x radio signal and better....everything!
I would advise against immediately using third party apps upon migrating to any new platform. I think that thoughtful implementation of user supported apps is something best done after a stable environment is established. Just my opinion though.
It's very reliable. Things get unreliable when dealing with certain 3rd party apps, bad devices, or ghosts. Can you post your z-wave details page in it's entirety?
Not at all. Put hub in pairing mode, put device in pairing mode (after excluding it from either the old hub or hubitat. Hubitat can do exclusions. An exclusion MUST be done regardless of the hub it's coming from)
support.hubitat.com will direct you to what ever support you need. It states as well to tag the support team and one will reach out and have a PM discussion if need be.
This is indicative of a weak mesh or ghosts
Several plug ins for that.
These are cloud based devices which Hubitat purposely has no interest in writing for. If there is no local API there is really no need. That is why they leave it up to the community to fill those gaps.
I have a 5500 sq ft house and no problems with signal on a standard hubitat. I also have strong z-wave and zigbee meshes
Thanks for the reply(s).
I will post an example of what I consider unreliable, the light is on but reports as off however the power is still reporting output. (see jpg) this is the 0x4A (074) itās a double switch and one of the two is working ok.
I will also add my Z-wave list.
Even though I repair Z-wave device and receive confirmation that it was successful it still reports as ārepairā
See my post above. Read the section about non-plus devices which that may be and what to do..
Looking at your z-wave table your mesh is a mess. No wonder it's unreliable. You have at least 5 ghosts that need rid of. (The ones without anything in the routing table with the discover buttons and even the ones with a routing button are incomplete pairings. You can try hitting discover but if it doesn't change it needs excluded and repaired) Nothing will run right until they're gone. Hit refresh on those lines until the remove button pops up and force remove them. You may have to power down the device the caused them in order to remove them. Again, if you haven't, read my linked post above.
Sounds exactly like my journey, landing at the end in Hubitat 
The migration process to Hubitat is not really "migration" but "scratch install" as you detailed. To add to that, the Hubitat radio is much more weaker than Smarthings - I think this is the key issue to many problems I faced.
On the bright side I can encourage you that after multiple re-installations and configurations, putting more money into Hubitat (Additional hub, repeaters and switching some sensors to newer ones), almost all things works at the end and the system is fast and working reliably now. It took ~3-4 weeks for 2 hubs to stabilize.
I still have one Kwikset lock in my garage door which still refuses to pair with any of the hubs but that is the only one left out for now (I'm thinking about adding another hub for the garage).
So bottom line is that it is a bumpy ride but at the end things would stabilize and work.
UI is a big downside on the Hubitat platform but thankfully I can continue using the ActionTiles one which I ported over from Smarthing - this one is no brainier and works well.
It's about the same. I also have a 5500 sqft house and have had no issues. I do have a strong zigbee and z-wave mesh and my hub is centrally located..
Hi! My name is Hal. You are telling my story so I know I am in the right place. I've been coming to this community almost every day for over a year and I haven't had the urge to go back to SmartThings for a long time. Welcome! Keep coming back!
That has not been my experience, and I believe others have stated the same. Is it a bad thing? Maybe, if you don't understand how to work around it. Once we understand how to compensate(repeaters) for what I see as a weaker radio then I came to appreciate the flexibility of HE
I have 1 standalone repeater but many mains powered devices. It's also spelled out here How to Build a Solid Z-Wave Mesh | Hubitat Documentation .
The biggest mistakes I see of people coming over are Ghosts (Which I will keep harping on putting a warning in the z-wave addon screen about) and older devices that are non plus. Even with a mix of plus/non plus devices , the non plus mains based devices become a bottleneck
If you are planning/hoping to make a gradual transition - keep in mind you may have to get a few new repeating devices. My Z-Wave mesh on SmartThings had three ZEN06 outlets that I put in locations midway from the hub and edges. When I started thinking about my migration, I realized that in order to build the new (Hubitat) mesh out from the hub, I would quickly disrupt the old (SmartThings) mesh when I removed those repeating devices. So I bought three new repeating devices (the Ring repeaters) to be the foundation of the new mesh. When the transition was complete the ZEN06 devices were mostly surplus (I think I repurposed one of them - I hadn't been using them for the outlets - only for their repeating capability.
Thanksā A LOT rlithgow1. The latency problem has improved significantly. Itās just been a few days, but I think you nailed it. I had to do the āUZB stick removeā thing on some of the devices. Dropbox - Hubitat UZB Stick How-To.pdf - Simplify your life
Iām surprised that I did not experience this problem in ST? What magic do they use to avoid this, and can HE copy that solution?
One problem persists āDevice status not updatingā I found another thread about this and I can see you have been active there as well and I will continue the troubleshooting in that thread.Device status not updating
However I manage to solve another problem I mentioned āturns on lights with light level 0% without any reasonā. This can happen when you change āDimming Duration Preferenceā on the device. I change it to 2 sec this will then dim the light to 0% in 2 seconds when turned off or on which is nice if you want a soft light off/on, and because you set it on the device it also works when punching the switch physically. When HE sent off command it seems to start the dimming process but at 0-5% it forces the device off and the device then saves this value as ālast setā and use it for next āpower onā command. At least itās my theory. Changing device preference back to default setting and the problem is gone. You can of course set the fade option in automation, but you miss out on physical interaction.
The issue is caused by the SiLabs SDK. ST is prone to it as well but ST uses a 500 Series chip whereas the C7 uses a 700 series (the c5 uses a 500). With the 700 it's much easier to spot ghosts. You can pair the stick to ST and likely see some ghosts there too.
Can you post your current cleaned up z-wave?
If you have any non-plus switches, they will not update on their own. This is because of the Lutron patent at the time. Once that patent expired, polling became part of z-wave plus and those will update status. The solution is to install the built in polling app to poll the non reporting switches.
The problem occurs on new z-wave plus devices (Qubino and Fibaro) I do have 2 devices without "plus" but those are working fine.
Have you tried re pairing them?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
