Maybe grab the latest?
1 Like
Update April 3rd, 2019
- fix for access error on field.
2 Likes
I installed WebCore a couple of days ago from this thread (still using the cloud dashboard to edit pistons) and have been having a play around, trying to get simple light pistons running.
Not sure if anyone else is getting this, however I’m getting errors in the logs and not the expected behaviour. My piston is as follows:
The devices are:
2 x Hue motion sensors (with stock drivers)
1 x Hue light strip.
I’ve also tried this piston with LIFX bulbs and I’m getting the same.
So the light comes on, but never goes off after the set time. I tried editing the piston so that on motion the light turns off. It worked and turned off so it seems like a Wait for X statement isn’t working. However still getting the same errors in the log (java.lang.IllegalArgumentException: null on line 946 (deviceHandler))
Have you updated to the latest version?
I was also seeing these errors, although the pistons would work.
The error has now been resolved with the latest webCoRE-Piston and webCoRE.src updated 04/04
With a simple piston like this, why not just use RM?
I was thinking the same.
Think the answer is here for that 
@Royski thanks I will give that a go.
@bobbles and @vjv the piston I had built (ported from ST webcore) is much more complex than the above test piston. The complex one just didn’t work at all (involving lights, motion, lux, HE modes etc). So I broke down the parts to the basics to begin seeing where the problem lies.
As good as RM is, it just doesn’t have the granular level of control that WeBCoRE does. I thought I would implement lighting control in WebCoRE first and then build out, if possible, the old ST pistons to perform bigger and better things.
1 Like
While I totally agree with this statement, and I had some pretty complex pistons running on my ST hub, I have found that I have managed to convert all my pistons to rules. A couple of my complex rules took 4/5 rules to replicate but I managed it.
As some have already said on the forum, 'Rules are Free'.
At the end of the day it's what works for you but be aware that webCoRE is not supported by the HE team so if you have issues with it slowing down your hub, which it did for me, then they will probably ask you to remove it before they can help troubleshooting your issues.
2 Likes
I agree with @bobbles. I use Webocre only for those functions that Hubitat cannot do on it's own. Even for those that require 3 or 4 (or more) rules to accomplish. I have been much happier with both Hubitat and with webCoRE since doing so. With no lockups traceable back to webCoRE either.
Not to open up over 1 year old HE "wounds" , but technically NO 3rd party app is. Evident enough from continued tried & tested Support suggestions / comments to disable all custom apps & drivers to investigate issues that are not readily solved by community members.
Not an active WC user myself anymore, but the stringent advice to stop using WC stems from the time a) before there were WC changes introduced specific to HE requirements, and b) before it appeared we now have a semi-dedicated WC support member in the form of @nh.schottfam to continue carrying the WC torch.
J
Hi @GatVlieg
I do agree with what you are saying.
I loved webCoRE and still do.
All I was trying to put across was the situation of webCoRE and its support with HE.
1 Like
I can say that I was a webCoRE Fanboy. In ST, I had every automation built into webCoRE. It did everything. So, I figured my port to HE would be simple. Just port my pistons. WRONG! Even removing all but one of my motion pistons, i could quickly see that RM was a LOT faster. Like a second or two faster to turn the lights on. And i'm impatient so that was a big factor for me. Don't get me wrong, I love webCoRE but if it's not going to work then it's just not going to work. Yes, you can use it for limited purposes but you're just giving yourself headaches if you try to use it like you did on ST.
1 Like
I’m about 35 Pistons in now on this latest code, with very few issues TBH. Any that I did have have been resolved by this latest update, and I honestly don’t see any speed issues compared to RM. I don’t use RM any more at the minute.
That said, I am watching things like a hawk.
4 Likes
They say that observing a thing affects it. Maybe it's only behaving because it can feel you watching it. 
2 Likes
Those 35 equated to various apps, and 95 rules, before I took another look at webCoRE. Although having the two hubs help.
Hardware on one, the apps on the other with no sticks
1 Like
I'm doing something similar to you @Royski. I have a second hub where I'm not running RM but instead have everything on WC. It sounds like you have many more pistons than I have but your experience matches what I'm seeing.
Are you saying that you are keeping all hardware on one hub and then using WC on the second hub? Does that mean you are using the built-in HubLink app?
1 Like
Yeah. All z-wave and Zigbee devices on Hub1, with very few apps.
On Hub2, I have all LAN devices and any virtual devices needed, and using HubConnect between them both.
Any virtual devices needed back on the first hub, I’ve added (just a few) It’s working really well, the pistons (just a few) run way quicker than they did without WC. I’ve even taken a good few Hue dimmers off Hue and put them directly on HE. They seem to perform way better than they did on Hue. All going V well 
2 Likes
Got to admit I’m finding WC pistons run quicker than RM and Motion Lighting. I don’t have a second hub so have it all on one so far.
1 Like
