WARNING about webCoRE


#26

But core was created after Bruce pulled rule machine due to ST instabilities, and ST never had a real rules engine in the first place.

Hubitat has a rule engine. I’m just totally blanking on the name right now, it’ll come to me :thinking:...


#27

For what it's worth this approach is the same with many service providers and product support policies - e.g. The I.T. department won't support laptops with software installed that's not on the permitted list. Or if my broadband was down my ISP wouldn't help me further until I plugged my router into the main telephone socket.

I've never had a smooth experience with webCoRE unfortunately, even running very simple colour bulb loops on SmartThings it would lock up my hub. That said, I think webcore.co is a brilliantly built interface, it's just the execution of the pistons built using it that has let me down in the past.


#28

App size is not an issue with any app to the best of our knowledge. It is not an issue with webCoRE, which is considerably larger than Rooms Manager. I don't believe we ever got to the bottom of just what the problem was with Rooms Manager. It is possible that it has been fixed; we haven't seen hub issues with it for some time now. I know it's frustrating not knowing the cause of a problem. What we did discover, and so did you, was that some hub slow downs evidently went away when Rooms Manager was removed.

Ultimately the responsibility for an app lies with its author (clearly an issue for webCoRE). We take full responsibility for all of the built-in apps. I know that Bangali takes personal responsibility for Rooms Manager, and I know that he is frustrated with the fact that there were problems. I hope there aren't any further problems with it, but that isn't really up to us.

We don't provide support for any third party apps or drivers. The support responsibility rests on the shoulders of the author. "Use at your own risk" applies to all third party software, pretty much on all platforms, not just Hubitat. Having said that you are free to load any app you want. Just be aware that doing so could have an impact on your ability to get support.

We provide the best customer support of any company in the home automation business. But there are both practical and fairness limitations to what we will do. For example, it is fair for us not to support third party software, and it is not practical for us to do so either. As our customer base grows we have to do some triage on support cases, and consequently we're going to be asking those seeking support to remove custom apps and drivers to see if their problems stem from these. Our experience is that usually this is the source of what brought the customer to support in the first place. In fact, the vast majority of our support requests concern third party code.


#29

I have a question (can test it next time I'm near my hub)

create a groovy app and put it in an infinite loop, and let me know what happens on the hub.


#30

TL;DR: Don't write an infinite loop and expect it to not cause issues on any OS under any development platform.

You can do that in any development platform (Visual Studio (C#, Vb.net, etc), Python, Javascript, batch, vbscript, etc). What do you expect will happen? On Windows in Visual Studio, I'm going to lock my system up and most likely have to reboot hopefully I've saved my work and haven't configured my buggy program to run on startup. That's not Microsoft's fault. They let me play with code on their platform. Same with every other OS manufacturer and every other programming language. Innovation would significantly slow down if they tied us down for fear of us hurting ourselves. I moved to Hubitat for the open development platform that allows me to break my hub and not worry about breaking yours too (unless I share my code with you and you install and run it, but that's your choice and not Hubitat's fault). I also was not sure of the future development abilities of SmartThings given their acquisition by Samsung and overhauls of the platform which have received wildly mixed reviews. Hubitat has been awesome and accommodating at helping developers figure out issues, implementing solutions into the platform for developers, taking great ideas and implementing them into the core system, etc but they are not required to do any of that. Don't write an infinite loop. Bug check your code. Get alpha and beta testers that are willing to help test your code if you plan to release it. Own your own code, support it yourself or be responsible and pull it down.


#31

A post was split to a new topic: Hubitat's business prospects


#32

11 posts were split to a new topic: Custom app support


#33

It's a reasonable policy.. They are NOT saying they won't provide support to people using WebCoRe, rather their first step will be to have you remove it - and if that "solves the problem", they'll consider the problem solved.

A better analogy is if you put an after-market turbo charger on a car under warranty. If you take it to the dealership for a broken tail-light, they will (hopefully, if they aren't a-holes) fix the tail-light. But if you go in complaining about gas mileage or the engine not running right, they're going to tell you to piss off. They damn sure are not going to try and fix the turbo charger.

bravenel is giving us the "policy". If you contact support for something that clearly isn't WebCoRe related and they hassle you about it... then complain. So far as I've seen, Hubitat support is one of the best things going for it, and that's really saying something considering its other strengths.

Even if the "policy" is:

"If you have webCoRE installed as an app on your hub and you contact support, the first thing our support team will tell you is to remove WebCoRE. Our support team will not put in effort on your behalf if webCore is installed on your hub."

It clearly means "if WebCoRe [remains] installed"... and that doesn't mean all the Hubitat staff have suddenly lost common sense, and will refuse to listen to you about a bug or something. But if Hubitat tries to "support" WebCoRe (or everything WebCoRe may cause), then their support level will suffer for everyone.


#34

See, if you follow your analogy, I read this as saying that if you came in with a broken tail light, we won't fix it till you take the turbo charger off. And that is what has been said by Hubitat staff. No matter why you contact support, if you have webCoRE you will have to remove it before they will help you with anything.


#35

ModernDeadHorse


#36

Dead-ish horse: "A little to the rear please ... ahh ... yes, that feels better ..."


#37

Well, until people stop saying the exact opposite, I'm going to respond. No one is making you listen.


#38

tenor

Sign me up for the dev/testing team. I want to see T-Shirts...


#39

#teamHoRE


#40

Even when port 80 is broke 8081 works, so really we just need some isolation for custom code. That is the job of the platform. I’m saddened by the lack of responsibility shown here...


#41

Patience! This issue has only recently come to the fore. We are going to address this.


#42

This has had a bit of a silver lining for me. I've dumped webcore and re-written all of my automations in a dockerized home assistant/appDaemon, addressing all of my hubitat connected devices via MQTT.

The MQTT support on hubitat, while less than perfect, is still surprisingly reliable and with an exception or two my automations are all faster and vastly more reliable than they ever were on webcore.

I've also been playing with node-red on Home Assistant recently and it's rather amazing. Remote controlling HE via MQTT is a legitimate path forward if you're looking for more complex and powerful automation tools than Hubitat currently provides, though I'm sure it's also not supported :wink:


#43

While the MQTT app is a community-created app and "not supported" in the sense that Hubitat won't deal with it any more than they deal with other third-party code (that's actually not a good metric: they're exceptionally helpful, beyond probably any other company in this space, but hopefully the point is still clear), I don't think anyone has reported problems with it. Certainly nothing like webCoRE if there are any.

I've got to ask, however: what can you do with AppDaemon that you can't do with a custom app running directly on Hubitat? I've used webCoRE (on both ST and Hubitat), Home Assistant with AppDaemon, and Hubitat (and ST) with custom apps and found the power about comparable. WebCoRE was definitely the easiest to use to create automations, while custom Groovy code is a bit harder (or not really harder but more prone to errors that webCoRE prevents you from making in the first place, including syntax "tyops" and whanot). AppDaemon was probably the hardest, in part due to the fact that, in my assessment, Home Assistant doesn't "abstract" device capabilities as much as Hubitat does (and checking logs for errors and whatnot is...different than seeing them in the "IDE" or HE environment itself).

Is it just that you've got Python running directly on a "regular" computer (including a Pi or similar) and thus can use whatever libraries/modules you want instead of the subset of Groovy that Hubitat lets you use? I could understand that, but I'm still not sure what use I'd have. There might be cool ideas I'm missing out on. :slight_smile:


#44

These are all valid points. There probably really isn't anything I could do on appDaemon that I couldn't do with custom apps in groovy. The one difference there would be that an errant loop on my appDaemon container isn't going to takedown the hubitat like it might in the local groovy interpreter. Because appDaemon is containerized in hass.io, It's just a click to restart the appaemon container and be back up and running.

There are a couple of other things I like too. First off, HA seems to have better support for IP enabled Home Theater equipment. All of my TVs, receivers, roku boxes, and chromecasts were auto discovered for example. Blink cameras and skybell doorbells were added with a 1 line config change each. I also have several IP cameras and those were a bit more hit and miss. I may be wrong about this, but AFAIK hubitat doesn't really address IP devices. Using Home Assistant, I have a single automation platform across all devices.

Secondly, I don't have a large house but if you do you can address several hubitats from a single HA installation. That might have some appeal to some people.

Finally, yes right now I've got hass.io running in an ubuntu VirtualBox on a "regular computer". I just like a unix-like development process better! I can write code in the text editor that I like, keep it version controlled in git, deploy with a simple git pull, and tail my logs to see what's happening. This sounds like more work perhaps, but it's actually been less effort to write and debug apps this way than in WebCoRE, or cutting and pasting groovy, simply because I have so much visibility into what's happening and can iterate really fast. The automations I've written are faster, cleaner, and more reliable too, and I'm no python guru either.

Finally, I've also been experimenting with node-red in the last few days and it's way more powerful than I expected it to be. So much so that I may write second copies of some of my automations in node-red just to A/B them.

There is now also git support in node-red but it's not enabled by default in the hass.io add-on version that I'm using. I think my next steps are to dump my hass.io VM and rebuild my environment in straight docker. This will make it easier to tweak the individual containers the way I like them. You can do that because... open source! I just find this setup really solid and trust it more. It's not, literally a "black box". I'm still doing some tasks on hubitat. Locks are one thing I've had difficulty controlling over MQTT. I'm also still using hubitat native presence and alexa support, though some of the node-red alexa stuff looks pretty amazing. In the end it's just nice to have options, and I can control things from whichever platform at whichever level I like.


#45

What native presence?