I believe I found the issue with the slowdowns in webcore in firmware versions after 1.1.2.121 but it's not something that can be changed from webcore's side of things. I've reached out to @bravenel in a private message.
9 Likes
I don't see that there is any obligation by Hubitat to support 'legacy' or 'custom' apps... however it will be in their interest to do so for 'significant' apps, at least until they have a large enough installed base. Larger companies require this before supporting new platforms.
Marketing HE as a near totally compatible alternative to ST allows ST users to transition without concern that they will experience lots of problems. This strategy has worked well for HE. I would guess a large number of ST users depend on WebCore so having that just work is a real incentive. There will be almost no ST RuleMachine users. Allowing WebCore users to transition as seamlessly as possible creates sales for HE.
The same is true for maintaining as near device driver and App code compatibility as possible.
Some apps and their devices can't easily be moved to HE because they are cloud based integrations implemented by ST. I believe that there should also be a mechanism to support these. It helps people make the switch to HE and generates more sales. That's why I think the HubLink app should be bidirectional and allow control of devices that have FTTB to remain on ST. Then you can just treat ST as a temporary peripheral for cloud devices and implement all your conditional logic on HE.
1 Like
You're talking about a desire to make migrating to Hubitat as quick and easy as it would be to migrate from SmartThings hub v2 to SmartThings hub v3. If you recall, even SmartThings themselves couldn't make that easy enough with v1. So how can we expect things to be "seamless" when we're talking about two different companies and two different products? This would be like asking Microsoft to make a migration tool for Mac users.
In my opinion the thing that would help ST users the most is an interactive app with more of a visual element. People are coming from a very visually oriented environment. Currently the stripped down minimal aesthetic is probably a bit drastic for someone who heard somewhere that Hubitat was "just like SmartThings but local".
How are things looking?
I've been working with @chuck.schwer on my theory that the slowdowns were caused by the 120 timeout limit, even though webcore wasn't necessarily hitting those timeout limits in normal operation. I verified that the changes made to webcore around the time of the update and the removal of the blacklisted methods were not causing the slowdowns. On my second hub I was seeing the same slowdowns especially on startup where the dashboard wouldn't load, and events would take 20-30 seconds to process instead of the subsecond range
He sent me a build of 1.1.3 today that had the timeouts disabled and everything worked great! Webcore and the hub stablized within 3 minutes of bootup with no slowdows or errors, and the dashboard loaded correctly. I'm not sure what the next steps are from their side, but in the meantime, until they announce them, the last version of 1.1.2 (right before the time limits were introduced) should run webcore correctly.
5 Likes
Sounds like progress! I rolled back to 1.1.2 and as you say, everything is working fine.
Thank you for the efforts - hopefully a resolution is found soon.
1 Like
i'm on the latest of everything and i haven't had a issue, but i do only have one piston running?
edit there is a new update so will try that 1st
That is definitely a factor and why I didn't know anything was wrong in the beginning. I did the development for 113 on my second dev hub with only a few pistons, and it all worked great. When I moved all my pistons over, that's when I saw all the issues everyone else was seeing.
1 Like
yeah that's the new update i just noticed
I updated about two hours ago. Noticed that the stuff i had in simple lighting seems to have stopped? but webcore is working fine.
No changes in this release touched Simple Lighting. Could you verify that the devices in question respond if you switch them from the device detail page...
Yes, I can control it from the hub interface, but it does not trigger when I open the door. The task is to turn on my lights when the door opens. I'm pretty sure it was working before I updated, but there's not a way to tell anymore. I just noticed it when I went up to feed the dogs. My pantry light wasn't responding as well at that time. I've since ditched the pantry light in simple lighting, but still have the garage lights in the app. I will go back to my door and make sure it is not responding. It may have just been a glitch. I'll also check my living room still on simple lighting.
I just went and checked and I think something's made my contact sensors unresponsive. Probably not the interface. I'll do a repair and see if it can bring them back. Hope I didn't scare you;
I have a ST Contact Sensor on my pantry doors that frequently needs to have its battery pulled and reseated to become responsive again.
1 Like
I just hit it with a magnet and it looks like it's responding. it also shows in the interface when it's open and closed. Just not sure what's making it act like that. investigating
I thought WebCoRE might be an issue so I completely removed it and installed the latest code. I only have one piston running on it. I use the WebCoRE presence to turn off a switch:
It seems to be working, but I get the following error:
I'm not sure what it means regarding the 'dev'. I didn't see that before I removed and reinstalled everything. Any ideas if this might point to something that would help things (much less why I'm getting the error)?
go to apps in hubitat. find the webcore listing. Your pistons are listed there click the link for that piston from the apps page and it will open a settings page. Just click done. That will fix the error. you have to do that for each piston for the time being. They're working on it.
2 Likes
Thank you! I love the fast help and response on these forums. I just did it and I'll post up later if it helps.
1 Like
I just wanted to add that I'm noticing that my complex pistons are not running like they used to. It seems that when things are more than one layer deep, they're not executing. It could very well be my style, but when I separate things out to separate pistons, then they run just fine. This has caused me to have a LOT of pistons running. Is anyone else seeing this?
