I haven’t noticed any if these problems in the last year. The database getting full was the only one that really annoyed me as I did need to restart the hub occasionally and occasionally press an extra few buttons to repair at boot time. (Also surely with a mesh network the quality of the antenna doesnt matter much? They are regulated/recommended by Zwave so Im surprised there is much variation)
However the last 12 months I haven’t had to do anything and it’s been absolutely rock solid. Updates are seamless, the features are so rich, and the community is building some awesome things whilst being very responsive. Touch wood, not a single hiccup.
The app is the one area of weakness but there are so many great alternatives that I have no regrets at all about hubitat. Happily recommend it to everybody now, even totally non-techy people if they are interested, as it’s easy to learn.
You can either copy and paste code (exactly like the Groovy web IDE here), or there is a search app (hubitat package manager) which will automatically install drivers that you find from search.
For actually writing them, it’s also the same as ST used to be, but there won’t be many things that haven’t been written already. Rule machine is the most advanced tool to do so many things without having to actually code.
I have 3 V2 hubs. When adding Hubitat C7 in the same locations, zwave and ZigBee signal levels were much lower. Especially zwave. The antenna mod mentioned over in the Hubitat forum has many rave reviews and makes the performance better than most.
It definitely matters. On C7 I had many devices that would not connect directly to the hub vs ST. After the antenna mod people on the forum say most devices now connect directly, no hops. And at 100kbps. I don’t think the zwave alliance tests relative antenna performance on any devices, it just has to communicate at a basic level.
I agree and as I did said there are many many pros for going with Hubitat. I was just saying it’s not perfect and there were things I felt I lost coming from ST.
They can be created using the API. A POST to https://api.smartthings.com/locations/{{locationId}}/modes with body { "label" : "{{Name of new mode}}" } should do it.
I’m a little surprised they haven’t made it to the CLI yet, but I guess they have lots to do.
The first notice of a deadline for the death of Groovy pushed me to taking action on migrating to a new platform. After some research, I settled on Home Assistant. The migration of all my Z-wave and cloud connected devices took probably a few effort-days, and more importantly, my wife is perfectly happy with the new automation.
To your point about frustration, moving to HA after years of dealing with the vagaries of SmartThings was like opening up all the windows in a house that had been shut down for a year. The transparency of automation and operation was almost … breathtaking. Everything is in code you can see, everything (e.g., device and entity states) is inspectable through the local web UI, and everything is logged. It’s all running locally except for cloud integrations. The community is very active, and there are integrations and templates for darn near everything.
Even better, there is an actively-maintained integration with SmartThings, so you don’t have to migrate all devices at once. In my case, a few Zigbee lights are on Still on ST, and the integration works well enough that I’m in no rush to migrate them.
There is a downside: You have to be comfortable with using or at least reading the YAML language for many configurations. If you’ve ever dealt with Groovy, YAML will be a snap.
I don’t want to hijack this thread to talk about HA, but feel free to DM me for more experiences.
It’s brilliant. But it also has issues such as configuring external access which proved a bit of a nightmare when I had local devices connected via WiFi.
The process for creating routines is just not as easy and it’s very much community based.
Lastly, I had to run a pc which took alot of juice and my old NUC couldn’t handle that plus anything else.
If I’m going to buy new hardware I think it would be hubitat.
Does anyone know if ST’s “Custom Monitors” SmartApp is going to get migrated? I don’t recall reading anywhere in the relevant posts about it, so I assume that means no.
My current monitors trigger an Arlo camera recording based on motion. It looks like routines can provide equivalent functionality - has anyone happened to try this yet?
In general ST’s Zigbee and Zwave antennae are both above average. I’ve only heard of Wink’s (ABNORMALLY powerful and borderline out of spec) signal to be stronger. I’ve found almost all others to be less ‘powerful’ But with all things Zwave / Zigbee - more repeaters.
Also if using HA or anything that requires a Pi and Zwave or Zigbee - Assume you need a short extension cable and/or hub to get the stick away from the Pi’s noisy USB3 ports. Trust me. (Edit: Yes, ODroids and most NAS boxes running as Docker hosts too…)
With some Zwave devices I need to get the ST V2 hub within a couple of feet to connect. And since I am on PG&E, one of their frequent power outages can cause these devices to drop off. I even see this with some zigbee stuff directly connected to ST.
But with HUE… not a single issue! Never, ever! And even my decades old x10 devices have never been an issue. Seriously has me thinking Zwave sucks (at least in use with the ST hub), and wanting to replace the few lights I have left on Zwave with HUE.
But I need some switches to do non-light stuff, and when these drop off I am left having to use a long ethernet cable and extension cord to get the hub close enough to disassociate and reconnect (which is a huge PITA). Sure wish Philips would introduce some high AMP outlets… then I could be done with all this crap.
BTW… the HUE API is wonderful, and seamless between both remote and local operation. Everything works when I am away, as well as when I am home and the internet goes down.
Early Zwave devices did not support NWI (network wide inclusion) so they always needed to be within hub distance to connect. Add to that reflections, mirrors, appliances and ductwork. NWI was added in the 500 chipset but not all devices implement it. Any routing devices between the device and hub also have to support it. Of course locks and other security devices only support a “whisper” radio mode to prevent eavesdropping during communication.
Yup… and a couple of mine (including the one I use to control my water heater) are that way. But I have had issues with newer ZW devices as well (GE/Jasco) after power failures, which has me wanting to avoid it all going forward.
Zwave itself is fine (one reason Amazon continues to use it for the Ring Security system). The SmartThings’ implementation of it, however, is…idiosyncratic.
I thought that was the case but its not actually true. NWI was optional on 500 series. You have to check the device certification on the alliance to see if its configured. You can see it in the XML version of the cert:
<Supports_NWI>false</Supports_NWI>
