I don't use fuelstreams, however for me none of my simple pistons will run. They are set to run at Sunset or just before and at Sunrise
Running the current WebCore code, not sure what to try, other than to downgrade
Rick
After this update I'm getting the following for my Garage Door Contact Sensor?
dev:3632018-08-19 10:41:13.984:errorgroovy.lang.MissingMethodException: No signature of method: dev15346387021152093280393.sendHubCommand() is applicable for argument types: (java.util.ArrayList) values: [[840400025801, delay 500, 8405, delay 500, 8002, delay 1000, ...]] Possible solutions: sendHubCommand(hubitat.device.HubAction) on line 376 (parse)
This is a driver issue, what device and driver are being used here?
Yes. That is the correct location of the current groovy files. 
@mike.maxwell it is the GoControl contact Sensor? The sensor is a tilt contact sensor? I never had a problem before now?
We will look into this.
Thanks @Matthew.
I just wanted to make sure as I'm having some minor issues with webCoRE and there is no point in querying if I'm using the wrong files.
Thanks again.
What driver are you using?, our generic contact sensor doesn't have a line 376.
Nothing is working on my system since updating to 1.1.3.113.
Lot's of MonoPrice plugs and motion sensors. Sengled and Cree bulbs. Have 3 Aeon MiniMotes also not working.
Last 4 updates have caused zigbee devices to become disconnected and I've had to add them back.
None of my Webcore stuff is working properly after updating to 1.1.3 and I'm running the latest Webcore code. Previous 3 hub updates before 1.1.3 never impacted webcore and webcore was always on the latest version of code. All of my pistons have worked flawlessly up until this latest hub update.
After updating to 1.1.3 I've got disconnected Zigbee and Zwave devices and this is happening even though my mesh is full of Iris Zigbee\Zwave plug repeaters.
I have updated to 1.1.3.113. Neither of my WebCoRE pistons are working. They are both very simple. Once takes the presence sensor and, when I arrive, it turns off my alarm switch. The second is a series of lights turning on and off when a virtual switch (My Shower) is turned on.
I run a trace with full debugging. In both pistons, it doesn't see the virtual switches.
Here is one of the errors I get:
[app:1774](http://192.168.1.34/logs#app1774)2018-08-20 16:45:58.243:info╔ Event processed successfully (97ms)
[app:1774](http://192.168.1.34/logs#app1774)2018-08-20 16:45:58.219:trace║╔ Execution stage complete. (15ms)
[app:1774](http://192.168.1.34/logs#app1774)2018-08-20 16:45:58.216:debug║║ Condition group #1 evaluated false (state did not change) (9ms)
[app:1774](http://192.168.1.34/logs#app1774)2018-08-20 16:45:58.213:debug║║ Condition #2 evaluated false (5ms)
[app:1774](http://192.168.1.34/logs#app1774)2018-08-20 16:45:58.211:debug║║ Comparison (error) Device ':1bb93d8aa491a4788749f7bcd363f20d:' not found changes_to (string) off = false (0ms)
No matter what I put in the execute "If", I get the same message. I've removed WebCoRE and reinstalled the app and created a new piston. Same results though.
My WebCore pistons weren't working either on 1.1.3.113. It was suggested to re-load all the WebCore code into HE, which I did and today everything worked as designed
Might be worth a try
Rick
1 Like
I did the exact same about ½ an hour ago and now I'm not seeing that error!
Was definitely worth the try!!
Thank you.
This thread makes me realize how nice it is to be able to choose if/when I roll back or upgrade firmware updates instead of them being shoved down my throat. More encouragement for me to move off ST sooner rather than later.
4 Likes
@mike.maxwell the system driver didn't work so I got a driver that someone wrote. It was the GoControl Contact Sensor Driver. Sorry for the misunderstanding.
Finally did it. I completed removed webCoRE and created what I could as Rule Machine rules or other 'Apps' that came close to what I was doing in webCoRE. I am on the latest firmware again now (1.1.3.114) and I have no lag and everything is back to the snappy responses I use have on Hubitat. I really liked webCoRE, but I have replaced almost everything I was doing there with other methods and the result is far more consistent and speedy. The few things I was not able to completely replicate from webCoRE I did find 'close enough' alternatives. I will take the speed and consistency over a laggy inconsistent platform as a good trade off for a few minor functionality items. I am back to 'Happy' with my system. 
[UPDATE] I knew it! As soon as I removed webCoRE .... they fixed it (maybe?). 
9 Likes
It's no longer catastrophically bogging down the hub. However, I did reinstall it to test, and I did notice the tiniest delays (not worth writing home about). After a few days of near-instant native automations I've become ultra sensitive to the slightest latency.
We did some timing ourselves while trying to find the cause of webCoRE's issues. We noticed that a webCoRE piston takes around 450 msecs to execute from start to finish. I don't know where in that time frame the actual action takes place. It takes a built in app maybe 50 to 100 msecs to run.
350 msecs is a noticeable delay.
Don't hold me to the specifics on these timings, as we noticed this while in the midst of a lot of things going on. Point being, webCoRE has a lot of work to do before it actually turns on the light, as compared to say, Simple Lighting.
Edited to add: Aren't you glad there is not cloud latency in the middle, for either?
3 Likes
@bravenel - I have everything in RM because there is not an option in Simple Lighting or Motion Lighting to use "Set Level" independently to control a light. The specific use for this in my case is for Sengled Classic bulbs, of which I have many. Their switches are always on, but the automations deal only with setLevel in order to use their smooth dimming functionality. Are there any plans to add this to SL or ML?
1 Like
I'll be looking over the next week to try and improve that number. It's much better than it was originally which was around 700 - 1000ms per execution before optimization, but I'm sure there's room for improvement. Having dynamic settings for child apps would really help to push it down another 100ms. I instruct that users open up the child piston app and click save to get around it, but would be nice if updateSetting went and created the setting automatically for users that happen to miss that.
There definitely is, though, a lot to do behind the scenes compared to an app like Simple Lighting.
3 Likes
By this do you mean that you want only setLevel commands and no on/off commands? That might be very easy to accomplish.
