Interesting.
Announcement - Changes to Legacy SmartThings Platform
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.