Wouldn’t option 3 be move to hubitat?
Announcement - Changes to Legacy SmartThings Platform
prjct92eh2
#56
This thread is about SmartThings changes. To your point, I suppose option 3 is webCoRE does nothing and if a user wants to keep using it then they go to Hubitat.
bthrock
#59
That’s huge news…including and especially this (emphasis added):
This is also in the works and will be made available before anything happens to WebCore. There will likely be some manual work involved for users (i.e. post the converted JSON to Rule API using the rule builder) but it is planned to be minimal and straightforward.
orangebucket
#60
It is a welcome, if perhaps belated, clarification of what is going on. It was originally suggested that the intended result was to have webCoRE running on the Rules API, with there being some uncertainty (particularly from me) over whether ST would be developing their proof of concept or whether the community would be expected to finish the job.
It now seems ST are looking towards having their own GUI for the Rules API, together with a rules generator for converting existing webCoRE pistons. They can then turn webCoRE off. I’m happy with that, but I am sure it won’t suit everyone.
GRClark
#63
Well that certainly doesn’t offer much hope there’ll ever be a new webCoRE now does it? Hate being in this position where it’s either I give up the main driver of 99% of all my automations on SmartThings or I endure the pain of moving all my devices and automations over to Hubitat.
WCmore
#64
May I ask how you heard this?
If true, for some strange reason, I find this positively liberating… I’m going to bet that Adrian can do much more while unaffiliated, than he could with going thru management or red tape at SmartThings…
Let’s just hope his interest still lies with SmartHome logic…
prjct92eh2
#66
If anything it probably raises the chances of a revamped version of Webcore that works with Rules API. I’m sure @ady624 can’t say why he left, but maybe he can say if he’s allowed to work on Webcore now .
Alwas
#68
This appears like trolling. You’ve been badmouthing webCoRE on the SmartThings forum for over 16 months, telling people on a daily basis, sometimes five times a day, that they should either stop using webCoRE, or if they’re thinking about using webCoRE for the first time, not to bother to install it, and to use the inferior inbuilt Automations instead.
And now you’re interested in Adrian’s work status?
orangebucket
#69
Depends how you look at it I guess. Left to their own devices, the webCoRE Community hasn’t exactly been galvanised into action. So things might have improved from having no hope to an only hope. Rather depends on what Adrian wants to do really. That’s his business though.
chrisb23
#71
Blockquote
I think this will finally push me to get off my a$ and migrate my devices to HE.
I didn’t waste any time with that. If interested, here are some notes on my migration so far.
I bought a HE hub last week and started migration the day it arrived. I have over 100 devices (some are Alexa switches), and over 150 pistons in Webcore, many with complex automations that call other pistons. There was not a chance I was going to try to re-write all that logic and functionality in the rules API before the end of the year, if it would even be possible.
I set-up the HE hub. I installed Package Manager, and then installed Webcore. Next thing I did was install Echo Speaks, which I really had missed since ST banned it. Sorry Voice Monkey, you now lose my subscription.
Surprisingly, all my Pistons in ST were available in Webcore on HE. While the “Move Piston” option didn’t work, I was able to create new, duplicate Pistons in HE from the ST Pistons. I recreated them all, pausing all pistons that had scheduled events. I had to recreate all my Global variables manually. I thought about restoring a back-up Piston file, but I went with one by one to decide as I go if they need to be paused. The restore from file option probably would have been faster.
I looked into Hub Connect - This looks to me to only cause more work. All devices used in ST Pistons must be replaced with the new device in HE. and I only want to edit the Pistons once to update the devices. I have just been adding the new devices directly as they are removed from ST, instead of using a hub-connected device for an interim period. Note, calls to other Pistons will still be set to the ST Home instance. You must replace all execute Piston calls with the copied piston instance.
In ST I used default “My Home” for a name, and in HE I used default “Home.” I was glad it worked out that way, as it was easy to tell which Pistons were which, and I’m not sure what happens if you use the same home name in HE as in ST. It could get confusing when trying to update execute Piston calls to know which Piston is which.
I am moving devices over in logical groups now, basically one room at a time, plus any other pistons that are called by pistons I move over. Then I add the devices to the new Pistons, enable it if paused, and then I pause the old Piston in ST. So currently ST is still running most of my house, and some rooms are now on HE. It is allowing me to migrate over a longer period, with no significant down time, and without using Hub Connect.
For Alexa trigger switches, I am using the virtual motion sensors available in HE. I set them to go inactive after five seconds. These are working great to trigger my Alexa routines from Webcore, by setting them to active. I added a character to the end of all my HE virtual trigger switch names so I could tell them apart from the ones in ST. Then I just update the routines in Alexa to use the HE switch trigger to effectually “move” the triggered Alexa device over to HE.
I also had success using a virtual dimmer to trigger all my Webcore events from Alexa routines just as I did in ST. I trigger specific Webcore Pistons from custom voice Alexa routines by having Alexa change the dim level which is evaluated in an Alexa Actions Pistons that subscribes to dimmer changes. That Piston calls other pistons based on the dim value set, and then resets the dimmer to a default of “99” to see a change again for the next event.
I found for this move, prep is key. I first recreated all my Global variables and values, then set my categories, duplicated all my pistons and set their category, and then created all my virtual switches (virtual motion sensors) and then I enabled the Hubitat Skill in Alexa and added the virtual sensors, before moving a device.
Note, that unlike the ST Skill, with the Hubitat Skill you can (and must) choose what devices to have Alexa see, so you have to go into the skill preferences in HE to choose the virtual motion sensor trigger devices to be available. Another bonus with moving to HE is the ability to exclude devices from Alexa!
I am very happy with HE so far, and the speed increase from local execution makes me wonder why waited so long to move over to HE from ST.
Bdobrescu
#72
Stay tuned for exciting news for the webcore users from around the world!
Follow the latest [here]
ipaterson
#73
Yes it would have been faster. Restoring from a backup file is a guided but still one-by-one process. Unlock the file once and the dashboard remembers your progress. The restore wizard sorts your pistons “simplest first” to encourage you to recreate all of the basic pistons first before getting into the ones that use a lot of devices, global variables, HTTP web calls, and especially Execute Piston actions. I hope that people make use of the backup file and restore!
…
bthrock
#74
Can’t wait to hear! Seriously, it looks like the year is going out with a bang. Good news was just posted here: