So your argument is basically that the hub is perfect and any time it crashes is due to bad code? Convenient, given that we have no insight into the truth or falsehood of that claim.
I actually tend to suspect that's either mostly or completely true, but even then you guys should still be willing to have a look at WebÇoRE. It's not about right or wrong, it's about creating a maximally viable product.
I was under the impression that there was active development on WebCoRE on Hubitat(not from you guys directly but from a community group) or I wouldn't have jumped from ST. Whatever.
Though I know very little about Groovy at the moment, I'll do it myself. I had a look through the WebCoRE source this evening, and while it's a bit of a mess (the dashboards, and fuel stream stuff could all go right off the top), I believe at the very least I can hack in a switch to disable pistons at reboot. From there, in the next couple of weeks I'd like to revive active development of the patches witch allow it to run on Hubitat, or fork the code and start anew with a dedicate fork.
There are huge differences between RM and WebCoRE and yet both do the exact same thing.... they compile a rule into java byte code. Now since no one has access to their own hubs (unless you already hacked into yours) no one really knows what's going on between HE and WebCoRE.
It would be helpful to even see what's eating up the cpu like showing running processes on the settings page. Which begs to wonder.... HE is built on linux... linux has syslog... syslog can send the messages to a remote server.
If you are going to expend a bunch of time and energy, why not spend that time converting to the officially supported app? With a few edge case exceptions, it will do everything that WC will do. You are always going to be behind the curve with WC... Every time an update comes out, there is the potential for WC to break, then you have to wait for someone to fix it, or to have the time to fix it yourself. I was hesitant to rewrite all of my pistons at first too, but it wasn't nearly as much of an effort as I thought. I really don't understand why everyone clings so hard to something that is not officially supported, never has been, and then makes it the staff's problem when something doesn't work right. I know we are taking about more than just WC here but WC seems to account for about 95% of the hub problems I've seen pop up on the forum here.
I see people are getting issues with their hubs when running WC.
People are spending lots of time rebooting, and trying to diagnose what is actually happening.
My first thought was that instead of investing all this time in trying to find out what is going on, perhaps the time could have been better spent on converting all pistons into rules and have a more stable platform.
Do I miss WC? You bet. I liked the way pistons could be written and I'm not a coder which is probably why.
Have I now got everything working without WC? Yes.
Maybe give it a try and see if things become more stable.
Just my twopence worth.
BTW. It's been reported on this and the WC forum that global variables seem to cause mega problems when used on HE. Are you guys with issues using them?
Just my thoughts.
The other thing you can also do is by running WC on ST and use hublink/other Hub device and link HE to ST for those needed pistons. You don't even need a physical hub for ST.
Just being the fly on the wall here, I'm again a little surprised how negative things have gone.
Seeing history repeat itself.
I for one do feel WebCoRE is worth fighting for. I understand it's not made for Hubitat, so that breaks things.
But it would make programming my house so much easier imo.
I know Hubitat isn't developer first and I support the decision, but I see WebCoRE's interface as a benefit to a users over developers.
I avoided webcore when I moved over, and I feel like I am glad I did. If the built in rule machine does the same thing, I didn't see the reason to use something else.
I for one have had very few problems and my system runs way more stable than smart things. Just adding this here for new members in case they are trying to decide.
I don't think most webCore users realize what they are asking. This app was designed from the ground up to run in the ST cloud. The author of this app no longer supports it. You are asking for a startup to invest significant time and resources to force fit an application that wasnt designed to run on their hardware without the assistance of the author of the app. I'm sorry but when I think of the request for what it is (removing all emotion from the equation) .... it is simply ridiculous. I also want webCore. I loved webcore when I used it on ST....but it not designed for this hub. When I gave up ST, I gave up a lot of integrations including webcore.
Every time we revisit this topic, it's the same thing over and over again and it is simply tiring and frankly a waste of this community's focus. If you want to use webcore...of course go for it...but accept the fact that at some point your hub is going to crawl or totally flake out. It was YOUR CHOICE to install an app that has been repeatedly causing issues. Any hope of this happening is a wasted dream. The Hubitat staff would never say this because they have to be diplomatic but webcore will NEVER be supported. It would be foolish for them to do so...look at the headache it has created even though they have repeatedly said it is not recommended.
How far back do we need them to bend. SMH...this is exhausting at this point.
The title of this post is misleading. It has nothing to do with an issue with the hub. This is squarely on a 3rd party app, webCore. (EDIT: someone fixed the title )
webCore was never designed to work with Hubitat. It was created for ST and to work in the cloud. The author has abandoned the code and now works for ST. I can only assume he is rebuilding it to work as a native app within the new ST app.
@jp0550 has done an amazing job maintaining the code to work with Hubitat. But again, he didn't create it and has no obligation to continue to fix it.
To truly work with Hubitat, the code still needs to be ripped apart and have several non-working parts (fuel streams, etc.) taken completely out. Other things like global variables have been proven trouble makers and either need to be disabled or reworked.
In mine opinion, Hubitat has no responsibility to make any 3rd party app work. Not @Cobra's, not @stephack's, not @ogiewon's and especially not something that was abandoned by the original creator. Will they answer questions, sure. But to actually take the reins and make it work, that's crazy. That's for someone in the community to do. The code is there for the taking.
I too used webCore when I first came over to Hubitat but after having my hub crash twice I made the choice to learn Rule Machine. Best choice I've made with Hubitat. It simply works and like anything else, the more you use it... the easier it gets. @bravenel has also added so much to it as people make the switch to make it even better.
To sum it up... Stop blaming the hub for an app that was never intended to be used on it. Either find a way to fix the app or move on. Pretty simple.
@stephack I'm not asking for anyone to do anything.
Just expressing my opinion that the style of programming WebCoRE uses is superior.
I don't think half of the people who have posted things like this want the Hubitat team to bend over backward to support it. Maybe the other half do.
I get the effort.
I just wanted @bill to know that he's not alone.
Maybe he feels like he's being piled on top of, I know I felt that way a while ago.
It's why I don't speak up anymore here unfortunately...
@keithcroshaw I think we all understand the benefits of webcore and I appreciate what you were saying...but when multiple threads are opened by the same person about the same issue it gets a bit aggravating. At least that's the case for me. This community should be moving towards something and not stuck in the mud discussing a 3rd party app that has been abandoned. Just my opinion.
I agree, Thanks for being constructive.
I think Bill was a little bolder than myself when the topic was closed without his permission.
Not that my issue was my topic, nor is permission any of us truly posses here.
)
