I have a notification in the Classic Smartthings app that I’ve been selected to migrate my devices my location to the new app. How is this going to affect all of my Inovelli hardware? It’s my understanding, and I may be wrong, that the devices will need new device handlers to function properly once the Classic app is shut down.
There are actually two different issues at play: first, the migration from the “classic” app to the “new” app. Second, there is the issue that SmartThings is totally revamping their current device type handler and SmartApp models (while all isn’t 100% clear to me yet, the trend is that they are ditching their history of hosting these themselves on the ST cloud in favor of an AWS Lambda or WebHook endpoint — basically others hosting instead of ST). Inovelli’s current DTH’s are of the “old”/ST-hosted Groovy type. I’m honestly not sure the “new”/future method is well documented anywhere yet…
In any case, for the time being, Groovy/ST-hosted DTHs like this will continue to work in both the classic app and the new app, as long as they’ve made the minor updates needed for that (looks like they have). Eventually, all hosted Groovy DTHs will stop working of ST proceeds as planned (they have announced eventual sunsetting of all of this), but hopefully they’ll give better DTH docs by that point and give third parties enough time to revise, as they’ve been doing for SmartApps. 
I got the same notification too, and I’m ignoring it. I don’t need “migrate”, I have been using both apps in parallel (along with the IDE, of course) for a long time. The new app is prettier for daily use, and the new “automations” are handy… and the Classic app is what I use when I need to get work done in terms of setup and configuration.
The sunsetting is really a silly move, in line with what Google did to Nest. Fortunately, it’s very hard to do vendor lock-in in Z-Wave (by design). I chose SmartThings because it combined ease of use with the flexibility to write my own code.
The day I can no longer do that I will switch to a more open platform (and, probably, my stuff will run faster because SmartThings is too cloud-heavy 
).
When I started with SmartThings, I told myself I’d stick to standard protocols, and preferably just one, to make it easier to switch platforms if things didn’t work out. Things did work out for a few years, but I eventually jumped to Home Assistant and quickly after to (the then-new) Hubitat due to frustration with ST’s cloud problems. Unfortunately for Home Assistant (at that time — it’s gotten better), the protcol I picked was Zigbee, and it turns out that most other platform are actually pretty bad at it. Hubitat was the exception (so I was thrilled when it was released, even though I had just switched), but again, I think Home Assistant has improved. Vera, which I briefly tried and returned, doesn’t seem to have–last I checked, its Zigbee compatibility list was a paltry dozen and half devices or so, and unlike these other platforms had no way to use custom device-support code. My Z-Wave devices worked pretty well, but I wasn’t really keen on the idea of switching everything.
So…not to derail this too much, but if you’re a fan of the “classic” ST architecture (not necessarily the Classic app itself — Hubitat’s administration vs. regular-use separation means that the respective apps generally play quite different roles), then I’d highly recommended Hubitat.
2 Likes
Thank you for your responses. I think in the near future I’ll move on from SmartThings to something with local control. Are you running Hubitat on a raspberry pi? If so how many programs can you have processing at the same time? I’d like to set up a pi-hole for my home network as well.
Hubitat only runs on their own hub, but I am indeed using Hubitat. (I have previously run Home Assistant on a Pi, but now I have it in a VM. It no longer does any automation for me, but it’s an easy way to not miss the history charts it has built in…one feature I kinda liked.) Both are good local options. Neither has a hard limit as to what or how much you can do, though in the latter you at least have the choice to throw more hardware at it if you think you have a lot going on and doing so would be helpful (something you don’t entirely lack in Hubitat, as a few users do indeed split the work between multiple hubs in various fashions). But the slowest thing in any platform is likely to be your Zigbee and (especially) Z-Wave networks, so carefully planning those meshes and thinking about what kind of traffic you regularly create on them (do you really need a power-metering smart plug with that low of an interval?), I think, is likely to get you the best outcome no matter which platform you use.
1 Like
I started the migration from classic app to new app and one of my Red Dimmers from Innovelli failed to migrate as I am using the custom handler to operate another switch using double press.
Another Red dimmer which doesn’t use any custom routines migrated fine. Talking to ST support and they are saying they cannot help with any custom handlers. So it appears until we have Innovelli suppor the features with new app, I am out of luck.
Custom device handler or routine? They are two completely different things. AFAIK the new app will work with most if not all device handlers and I’m sure we would have heard by now if Inovelli’s DHs weren’t working with the new app.
On the other hand, I don’t think that the new app supports routines, so you’ll have to find another way to replicate those via another function.
Thanks for the clarification. I didn’t know what caused the migration from classic to new app failed for this switch, but ST support says it could be due to device handler, but considering my other Red Switch migrated fine, I now think its due to the scenes setup on the failed switch.
I have it configured so double pressing the switch turns on/off a diff z-wave switch. I guess this is a routine that is causing the migration issue?
Has anyone with such scenes setup on Red Dimmers and using ST classic been able to migrate to new ST app?
All of my inovelli devices work with the same DTH in both the old and new apps. Functionality is different since the new app doesn’t have the graphical equivalents, but the DTH shouldn’t control what does/does not work between the old/new app to the best of my understanding.
You’re sort of on the right track @kreene1987 . The custom capabilities per device between the new and old app on some devices are not directly compatible. It has to do with the way the code is written for presentation, custom capabilities and execution. My Inovelli 4in1 show temp on home screen Classic App and displays motion on the new.
To add insult to injury the latest plans to drop groovy is not going well with community developers to get everything to cooperate and function as desired. There are alot of changes in the works for ST, maybe good or bad depending on what the end user requirements are from what I have heard. I have devices that still don’t show all functions in the new app even though ST has sent me migration notices claiming my devices are operational in the new app. Functional to a degree, but not all capabilities show up. In addition to trying to get my own smart apps and dth working 100%.
I did the migration over the weekend - there is functionality missing in the Red Series Dimmers in that there is no way to control the notifications as in the Classic App. Are there any plans to get that functionality?
It is my understanding that the child devices show up in the new app, mine did. Do you see the child devices anywhere in the new app?
No I do not - are they listed as separate devices? All I see is the main switch.
You might exclude/include because when you include it does the children.
@Yooshaw What i’ve noticed is the notifications don’t show up on the dimmer device page like they did in the classic app but if you are looking to trigger the notifications using a custom monitor or smartapp automation they show up as triggerable devices like a separate light.
I started with a Kasa, but when decided to go with SmartThings (and a v3 hub), I thought I would stick to just one (other) protocol: Z-Wave. I didn’t work out that way, sometimes I couldn’t justify the cost of a Z-Wave device (especially sensors) when there was a good zigbee one available and I didn’t mind routing the automation through the hub. So now I have quite the mix: 20 Z-Wave devices (12 Inovelli switches, 4 other switches, 3 sensors, and an Ilumin bulb), 22 Zigbee devices (mostly IKEA and SmartThings branded; 8 buttons, 5 sensors, 4 outlets, 4 bulbs, and a relay), and a scattering of WiFi switches. I actually like the appearance of the new app for day-to-day use, both at home and away from home. For admin, it’s a mix of the new app (for the new Automations), the Classic app (for keeping track of what SmartApps each device uses), and (as the advertisement goes) for everything else, there’s WebCoRE.
When the turn off the Groovy stuff, however, I will be leaving, unless there is an individual-tinkerer-friendly replacement. I think I might be OK to wait and see about that. If/when that happens, the two options I am considering are HA and Hubitat. @BertABCD1234 it seems like you have had good experiences with Hubitat with a mixed-mesh setup like this. I’m hoping that it also will be able to integrate with Google Home and talk to my cloud-managed devices. Also, in the SmartThings world, I’ve gotten quite used to remote use, both for day-to-day things like turning off a switch, as well as admin-ish things like adding a new automation or changing the parameters (e.g. Inovelli LED colors) on a switch; I hope I can still do that in Hubitat.
Really, I’m hoping SmartThings doesn’t drive me away by making it hard for me to write my own code for my own devices. But if they do, I hope that the Hubitat hubs aren’t out of stock. 
Yes, I’ve had great experiences with Hubitat! Before its release (late January 2018), I had been using Home Assistant for a few months after deciding to move away from SmartThings due to the Great Daylight-Saving Time Incident of Late 2017 (which to be fair may have been more related to webCoRE than ST itself, but ST had/has no shortage of its own problems before and after this). At that time, I found Zigbee support to be somewhat lacking and Z-Wave support to be there to some extent but not great for all devices (some showed up in weird ways and I needed to make a “template” device for it to work how I wanted). Both, particulary Zigbee, have improved a lot since then from what I’ve seen, as has general setup and configuration of Home Assistant itself — you no longer need to edit a bunch of config files yourself, for example (but in most cases still can if you want to). Aside from the hardware, it is, of course, free if you wanted to try it. But at the time, I was certainly much happier with Hubitat: exactly what I wanted but with none of the work, plus not a lot more cost than all the hardware I put into Home Assistant (the hub was frequently on sale, though I paid pretty close to list price and still would). I think I still am, but I know people who like one or the other or both.
If you like ST’s “classic” Groovy environment, Hubitat reverse-engineered (or really nearly matched the public API to create) a near-clone, so it’s usually easy to port DTHs or SmartApps, though you may not need to — there are a lot of good ones built in. Many Hubitat Community members, to say nothing of the founders themselves, are also ST ex-pats, so you may feel more at home.
There is a Google Home integration (and Alexa integration) similar to that of ST — or at least the Alexa one is. I haven’t used the GH one myself, but it seems similar. You can totally control the Inovelli LEDs either in a similar way to ST (Inovelli’s drivers are nearly identical to the ST DTHs) or with a Hubitat method if you use the built-in drivers (though you’ll need Rule Machine, webCoRE, or a custom app to make use of the custom command this requires).
2 Likes