No updates other than it’s still under investigation.
Great, thanks for the update. Please let me know if any of us can assist somehow.
On a side note, when googling that error, it looked like that Tomcat JDBC driver defaults to maxActive:100, but the error in the posts above implies that it is maxed out at 50.
I’ve had a lot of pistons failing as well the past week or so. (30% to 50% of the time.) Sometimes, when I exit a piston, I see code that looks similar to the examples posted here, but it’s only there for a brief second, and it doesn’t happen every time, so I’ve been unable to read or screenshot it. I’m also on an East shard.
I have also started seeing (“if motion” then “turn on/off” a light) pistons fail. I created a similar scenario within the ST classic app (instead of webcore) and while the “motion sensor” and the “light switch” both show being activated in their logs, the light actually did not turn on 2 out of the 3 times i tried it in my simple quick test
fwiw, I opened a ticket with smartthings and was told to watch this thread for a solution, as this is where any updates would be posted.
Unfortunately this issue is bad enough that I ordered a Hubitat hub tonight. I’m really hoping this issue will be resolved before I start migrating things so I can return it but the wife is losing patience quickly. I’ve put a LOT of effort into WebCore and SmartThings, I’d really hate to have to recreate it all.
I should say that my biggest issue is WebCore pistons not recognizing that virtual switches have changed as a trigger. I’ve read of people setting up tests in SmartThings proper though where triggers are being missed without WrbCore being involved.
Seeing the same here. Twice this week my bride has ended up in the dark while bathing. There were other events too but those two are the important ones here at the moment.
I wish I knew if it was just a ST-WebCore issue.
Nothing to report @Brad_ST?
Same issue here. Please advise how the community can assist in resolving this issue asap. Thanks.
I sat at the order screen last night for quite a few minutes, but found that most of my bulbs won’t work with it. I’d need more than the hub.
I suspect the native automation would continue to work, so perhaps moving some to that would resolve some of the issues.
Any update on this problem? I also have found myself on habitat’s website multiple times but reluctant to pull the trigger and deal with re-pairing all of my devices (especially the z-wave in-wall outlets I have connected through repeaters. However, the longer this goes on the less choice I have in the matter.
FWIW, I created my bare necessity automations in the “new” SmartThings app. While my lights now turn on when motion is detected, the turn off “after no motion for X minutes” doesn’t reset when new motion is detected, i.e., leaving a room and re-entering doesn’t cancel the X minutes timer (similar to task cancellation on WebCore from what I understand). What a joke. This seems like a bare necessity code that ST can’t implement properly on its own.
Really hoping this is solved soon, but I’m worried that the ST environment is just too fragile for all the time and money I’ve invested (and continue to invest).
That’s odd, I feel like I should test that myself. I’d wonder if the native app is having the same issues as webcore.
I’ve got a spreadsheet with all of the devices I’d need to replace for compatibility reasons :-(. Smartthings wins for compatibility, and I think I’ll stick with it a little while longer. Heck, it’s only been about 2 months since I bought it and started this whole smart home thing.
I remember that being an issue from forever ago. I’ve been told that the “timer” functionality in the automation creator is just that, a timer. It’s not designed to reset. Seems kind of dumb to me. Can you use Smart Lighting for your lights? It works better and is local if your devices are local too.
My problem with smart lighting has been the lack of ability to add multiple condition switches. Example, I have several doors, fans and virtual switches in our bedroom than can effect whether the lights turn on/off automatically. I have used the Automation Creator to lump all of my conditions into a single virtual switch and then use that virtual switch within smart lighting. The lack of complex if/then/else can be overcome by splitting things into multiple rules. Kind of clumsy but it does work
FWIW, I’m seeing the same thing in webCore. But only occasionally. I’m going to rearrange my pistons tomorrow and see what happens. If that doesn’t fix it, I’ll move things back to native smart things apps. Ultimately, I’m waiting to see how the new rules API turns out.
I did try the Smart Lighting app in ST but ran into the same problem. Incidentally, when creating the routine in Smart Lighting, I noticed that the “turn off after X minutes” setting has a beta disclaimer.
I need to play around with it more before I totally give up on it, but for now I’m using ST native for turn on events and Webcore for turn off events. So far…okay but I’m sure this won’t work for one reason or another.
There is a similar thread going over at webcore. I too took a long look at the habitat’s device but did not pull the trigger. Someone mentioned in the other thread that the Sharptools Rules Engine is not having the same issue. I might check it out if I get tired of waiting for a fix here/webcore
Thanks! I’ll take a look. I heard about this earlier but assumed it would suffer the same issues as WebCore. I’m relieved to hear it isn’t.
Also, I re-wrote my lighting commands in the Smart Lighting app in ST and it seems to be working. Originally, I had created separate on/off automations (which did not reset the “stays inactive” timer), but combining on/off in a single automation appears to be working.
Hey, that’s good to hear. I’ll have to take a look at my pistons. I may be able to easily move some over to the automation creator.
As of about an hour ago these errors have been resolved.
Seems to be working for me! Although I’ve only resumed a couple of my most basic pistons for logging/testing purposes at this point.