1.1.1.19 through 1.1.3.114 not working for webCoRE

Nope. Not at all. If the developer of webCore was here working with the team to sort out a specific issue, I could see your point. The HE staff cannot be expected to help get every app ported over because someone feels entitled to a functioning 3rd party app without the ability to assist with troubleshooting the code within it.
I can't simply grab a piece of code from the ST forum and say...HE staff..make this work.

What I can do is take a piece of code that I wrote and/or completely understand and ask...why is this not working when it should. With this concept in mind, I have to say, the HE staff have bent over backward, taking the time to assist.

Webcore is simply a monster....and without the author available, running into issues now and even more so down the road is inevitable. If you use webCore do so with the expectation of problems at some point. That's why I chose to learn RM. Hate troubleshooting issues I don't have a proper understanding of.

10 Likes

@april.brandt it's a little weird at first but otherwise pretty easy to transcribe your pistons into RM. I've got most of my simple ones in there now and finally experiencing the "blazing fast automations" as promised. Knowing that it should theoretically be impossible for WC to be as fast as RM, it's hard to think about going back.

@april.brandt
I believe that they have recently created a separate part of the forum for RM related questions. I would try moving over one piston at a time and asking for assistance there. It's a great way to learn RM and you probably have the same questions a lot of RM newbies (including myself) have and can learn from. Quite a bit of what I learned in RM came from reading the solutions the community and HE staff have provided to other users. Whether they get WC working again or not, it's worth learning RM if even for the simpler automations. Why use a chainsaw where a butter knife can do the same job :slight_smile:

3 Likes

So you dislike AT and Webcore.... for what ever reason and instead worked with SharpTools to interface with HE and the new API layer to support it. And you push RM because it's native but yet offers only 25% of what Webcore can do.

How is any of that fair ?

Many people (hundreds if not thousands) jumped ship because HE made a promise to have everything run local and offer backups but in the process you blame Webcore and suggest that some software guy OR girl write code but make no effort to write up any coding docs that would help code in groovy for HE FW.

I still believe that HE can out do ST regardless of the current issues but ONLY if the developers here play the game fairly.

What is AT? I don't dislike WebCoRE and didn't say anything resembling that. We don't push RM. It's there if you want to use it. If you prefer to use other code than the built-in apps that is fine with us. We made that option available, so that speaks to our motivations.

The distinction that's being missed here is that we cannot support webCoRE. It's not our code. We don't know anything about it. We do support the built-in apps, and fix bugs that show up in them.

I think you are projecting motives and attitudes on us that don't exist.

3 Likes

ActionTiles and we had this discussion a week ago about it.

And your post above does show your dislike for Webcore in its current integration by suggesting someone to make a translator for it to produce native groovy. And you don't defend HE FW causing the issues either.

I'm projecting motives by what I read here and the major lack of docs. The 3 groovy examples that are offered are so primitive in functions its pathetic.

I know groovy well enough to code in it but even when I get stuck at it I can't find any docs that support your FW functions. I have to look at ST docs which isn't compatible for the most part for HE.

If HE isn't going to help with constructive posts or docs for custom DH and apps why do you even offer that as a feature ?

But at least here the developers to try to help which is more then anyone from ST did on the community forums so I have to give that credit.

1 Like

Please just stop pointing fingers and get it fixed. Make HE a happy place again. PLEASE. Shouldn't matter what 3rd party app i prefer to use.

It makes sense to me that SharpTools and Hubitat decided to work together. Not sure why that would be a point of contention. The developer of webCoRE works for SmartThings now as I understand it. I cannot see that Samsung would be happy if he were working with their competition. In fact, he may actually be forbidden under the terms of his employment from doing so.

I don't have a sense, and have actually seen @bravenel write that you can use whatever you want. Again, to me it makes perfect sense that one of the founders of Hubitat and the author of Rule Machine would want to help his customers by providing a solution with the built-in app he wrote. But "push RM", I have not seen happen.

The wonderful thing about this platform is you can run whatever you want. Whether it works properly is really up to the developer of that app or driver. But isn't it nice that you can (within reason and without breaking the internal databases), use the firmware version that works for you, backup the software, databases and all your settings for the built-in apps, and upgrade on your terms? ST never offered that and still doesn't.

5 Likes

I have NO idea where you got that idea from

I have had extensive help with both drivers and apps that I have been working on.
This is despite the fact that I was not working with included apps/drivers and the Hubitat team have no obligation to offer help.

Perhaps because I have respect and ask for help in a polite way?

Andy

6 Likes

Point me to HE docs that help newbie coders then. Don't suggest some smart software guy invent a translator for webcore pistons.

It's true really. If we want webCoRE to work, we should be talking to @jp0550 or @ajayjohnm, as they are the ones (and more?) who ported it for HE in the first place.

I tried very hard to convince Alex and Terry to do business with us. They refused. The result is that we implemented Hubitat Dashboard instead. Pre-release versions of Hubitat Elevation had SmartTiles installed as a built-in app. So, I don't dislike AT.

How you read that from that post is beyond me. I was making a half joking / half serious observation that any piston could be implemented in Groovy. Were that done, the result would be an order of magnitude faster and do the same function. Such a translator is possible. Making such an observation does not mean that I dislike webCoRE.

I can't defend what I don't know anything about. I have no idea why webCoRE has issues with 1.1.2 and 1.1.3. Do you know why? Does anyone know why? Whose responsibility is it to figure out why webCoRE has problems? It's not ours.

You mistake motives for limits on resources. It's not like we are intentionally withholding documentation, We are working on it as fast as we can. It was not our top priority -- making the hub work and be full featured was and still is our top priority.

Hubitat is probably 98% compatible with ST.

Would you prefer that we not offer this feature?

It's pretty clear that you are very unhappy with us and with our product. I'm sorry you feel that way. But, that doesn't warrant impugning our motives and casting aspersions.

5 Likes

i am on 1.1.2 and guess what -- webcore works like a champ. I tried all versions of 1.1.3 and the webcore tricks and it bricked my hub twice. The minute I went back to 1.1.2 my hub runs smoothly.

Now explain that ?

Precisely. I have much to say about the tone in here but I might get too honest and offend someone who obviously feels wronged on a deep level. I will read on just for the entertainment value.

7 Likes

Respect is a 2 way street... instead of posting a rude comment suggesting a smart guy to write a translator was my last straw of ignoring the underlying issue.

Who was I being rude to? I didn't write that to you.

We are not ignoring anything, and have spent many hours digging into people's hubs trying to understand what is causing their hubs to run slow. We have seen some code in WebCoRE that might be responsible for it, but really don't know. It's only an observation that there appears to be a correlation of slow hubs and running webCoRE. We don't know why, and don't even know it that's causal or coincidental.

You seem to think that somehow we know exactly what change was made in 1.1.3 that causes an issue with webCoRE. We don't. We have examined all of those code changes and don't see anything that should explain that. We are not in a position to debug webCoRE. It's good that you can run 1.1.2, and that it works for you on 1.1.2.

1 Like

I don’t believe I have seen any posts by @bravenel which could even remotely be considered rude.
And as an Englishman who by definition is part of an extremely polite society, I consider myself an expert on rude!

Andy

10 Likes

Fine....... there is a issue between 1.1.2 and 1.1.3 -- find and fix it. Stop blaming others without proof. You have proof then post it. Want to give us access to the hub logs then we can figure it out.

Where have we blamed anyone?

1 Like