these issues should be all resolved with the update of April 14th or later. Let me know if you see other problems.
Update April 16th
- fix for improper hashing of location ID
- email send uses async http.
2 Likes
Update April 20th
- Fix for time schedule subscriptions
Many thanks to @Royski for reporting this and helping find the issue.
4 Likes
@Royski, I' m very happy when I read your post. Could you give more detail : Hue bridges need connect to the HE hub with Webcore ? ( turn off radio ) ; Dashboard on hub server or hub client ? If still need to use RM, install on server or client is better ?
I want follow your way on my setup 1 HE server, 2 HE client, 1 ST hub. PLEASE give me some advice. Thanks a lot.
Ok a rough diagram on setup.
Hub_1 - All physical devices are connected
Hub_2 - Runs all apps and Hue
ST - Runs a couple of things I have no driver for as yet.
HubConnect is in use on all hubs, and Hub_2 is the coordinator.
I share a few LAN and virtual devices from Hub_2 to Hub_1 and ST.
My Dashboards are set up on Hub_2, with all other apps including webCoRE.
Hope this helps. 
3 Likes
@Royski, thanks. On your set up :
- Can Hue connect direct to both Hub_1 ( client ) and Hub_2 ( coordinator ) ?
- Hub_1, Hub_2, Samsung ST, Hue connect via wifi or wired ?
- Hub_2 ( coordinator ) is turn off radio , both Z-wave and ZigBee ?
- Speaker ( Echo ), LAN devices, ST virtual devices … on ST hub can shares to Hub_2 by HubConnect ?
- Hue connect to Samsung ST for double check status of the lights on mobile phone ?
- Use Pushover ( paid ) on Hub_2 ( coordinator ) and Push a Notification on ST hub via webCoRe for some contac sensor ( Front door, Back door … ) ?
Hi,
A little too far off the subject matter, PM me if anything more is needed 
-
Can Hue connect direct to both Hub_1 ( client ) and Hub_2 ( coordinator ) ?
It could but I dont need it. -
Hub_1, Hub_2, Samsung ST, Hue connect via wifi or wired ?
ST is via the cloud, so doesn't matter. And HE isnt WiFi. -
Hub_2 ( coordinator ) is turn off radio , both Z-wave and ZigBee ?
No, I just dont plug the sticks in, but you could disable. -
Speaker ( Echo ), LAN devices, ST virtual devices … on ST hub can shares to Hub_2 by HubConnect ?
All apps are on Hub_2 so I have no need to connect anywhere else. -
Hue connect to Samsung ST for double check status of the lights on mobile phone ?
Again, you could but I have no need as I use Dashboard -
Use Pushover ( paid ) on Hub_2 ( coordinator ) and Push a Notification on ST hub via webCoRe for some contac sensor ( Front door, Back door … ) ?
I have it on both ST and Hub_2 (you pay per receiving device - phone etc)
1 Like
Updated - see note 1 in this thread:
Current Release: Updated May 5th, 2019
- Ability to execute Rule Machine rules from webCoRE To use this capability you need to use the webCoRE dashboard site staging.webcore.co when editing pistons that call RM.
- Improved DST processing
- improved sunrise/sunset events to avoid double executions
- cleanups and bug fixes
3 Likes
There has been a small fix to today's kit, so if you grabbed the May 5th kit in past 2 hrs, please update webcore-piston.groovy file again.
2 Likes
I pushed an updated version, thanks for the report.
Updated May 12th
4 Likes
I was with the full intention to migrate from ST to HE so I bought my hub and I am ready to star transfering everything but I just start reading in detail the WebCore problems for HE and I am not sure now if is a good idea to migrate or not. At the begining of this post are some things that does not work correctly when using WebCore in HE. Is there an updated list of what is fixed and what is still a problem?? The reason I am migrating is that HE offers local control while ST does not but if I migrate and many things will be broken then I doubt is a good idea as actually ST works well but the problem is that if internet is down then I have nothing
I think the first post in this thread (I assume that's what you mean) summarizes issues that remain if you read it from the top down, but one is that your webCoRE dashboard might hang if you have large pistons. In the past, I saw something similar if I had large numbers of devices authorized, so I'd suggest limiting that to just what you need (that was before this revision of webCoRE, but it still can't hurt). If you've read about webCoRE causing your hub to hang, freeze, etc., this revision of webCoRE is supposed to have resolved those issues.
That being said, Hubitat has its own rules engine built in, Rule Machine. It recently received an update in the form of Rule 3.0 that allows you to create rules whose action execute more or less as an ordered script, similar to webCoRE. The UI compared to webCoRE is completely different, and you'll have to learn a bit of different terminology (rule vs. trigger, conditions, actions for true/false, etc.), but the power is comparable. There is lots of help on this forum if you need it. Obviously, you're in this thread because you want to use webCoRE, and if it helps with your transition, I won't discourage it--and the work this author put into this revision of webCoRE should be quite helpful. But it's still a large app (may execute slower than smaller, native code) and not officially supported (so you'd be in a better position with RM should you need to contact support). Before this revision of webCoRE, I bought a second hub to run some pistons on before I finally migrated everything to Rule Machine and custom apps--something I'd recommend anyone using WC consider eventually. 
(OK, so my custom code isn't supported, either, but it's a lot smaller and easier to understand, and very few custom apps have been known to cause problems.)
PS - Hubitat also has far more built-in/native apps than ST, or at least ones that are more powerful/useful, so some of the things you previously had to manually script you might be able to do natively now. Be sure to browse the built-in apps (and the documentation) to be sure you aren't expending needless effort.
Good luck!
I would have to investigate more about RM but after a quick browse I quickly found missing things that I actually have in WebCore such as the operators: "was", "was not", "at least" etc so I guess there should be alternative ways using RM to achieve same results but WebCore is so easy and powerful that I just would love if I still can use it in HE. Do you know if I have to be at home (and connected to my local network) to create my automations in RM and WebCore? I have noticed that HE automations are done in the hub IP address so if I am not home how would I enter to its IP to create automations?
For Rule Machine, yes. For webCoRE, no, not if you use the public/hosted WebCoRE Dashboard (as you did with ST)--that editor lives online and can connect to your hub over the Internet with the cloud endpoint. Automations it creates in either case do live on your hub and execute locally.
However, you can VPN in to your home network to administer your hub, including editing RM rules, if desired. Remote device control and monitoring can be done as-is from anywhere with Hubitat Dashboard (or SharpTools or...), so it's just the adminstrative side that requires LAN access.
This is not true. 
Here is a simple "at least":
For "was" and similar, you can use the appropriate operator along with a delay in the actions section (which you can now put before, between, or after any action or configure for an action itself and choose whether or not to cancel on truth change, roughly equivalent to Task Cancellation Policy in webCoRE). For example, when paired with the above rule, this will turn off "Scene 1" one hour after the temperature of Test - Virtual Motion Sensor becomes greater than or equal to 55 (unless it drops below that again):
That is a fairly simple "set" of actions (it's just one), but the possibilities are nearly endless, with Rule-3.0 letting you now include loops, conditionals, and comparisons to other devices or variables, besides just an ordered set of actions.
I'm not sure if that's what you really mean with "was" (I guess this would be more like "stays"?), but there is a way to do pretty much anything in RM now.
1 Like
I’m using webCoRE here on HE. That said, I have two hubs and it sits on my hub with no Z-wave or Zigbee enabled. It’s running absolutely fine.
A lot of work has gone into webCoRE to resolve issues, and for me it’s working well. That can’t be said for all I guess, and in the earlier days it did cause issues.
It’s not for all and I know it’s not advised to use it, but I can do what I need in one piston which used to be a lot of custom commands and rules in RM, or other apps. Each to their own 
2 Likes
I think you will find most things work with no issues.
The big thing missing is if you use $twcweather as those pistons would be changed to use a weather device (like apixu, etc).
For pistons using buttons there will be a small change (same line, one line) as HE manages buttons differently than ST.
Otherwise I expect you will see things are the same.
what I mean is all of those triggers and conditions available in WebCore. I guess there should be a workaround for all of them in RM but looks not that user friendly as in WC
So if I will still using WebCore in ST and starting using WebCore in HE is it possible ?? I have noticed that WC authenticate using a browser, so can the same browser have 2 different WebCore sessions open and running at same time?
Other question. I am thinking to replicate all my "things" that I have in ST in HE but as virtual devices so I can test before I officially unpair my physical devices from ST and link them to HE. Will the virtual devices behave the same as the physical ones in HE ?? this is only to test my pistons before doing real migration as if I do physical migration and then something do not work, will be really painful to unpair from HE and pair again to ST
thanks
