z-wave repair stuck for 90+minutes
backup and restore screen stuck for 20+minutes
everything else appears to be working (very slowly) but I have no idea of the state of the actual hub. Even a little feedback like uptime would helpful.
This black box sh*it is bs.
I initiated a z-wave repair because my second lock seems to have fallen off the network AGAIN, after working for the last 10 days. Not sure how you can blame that one on WebCoRE. Ran the z-wave repair in hopes of clearing it up but the z-wave repair running notification was stuck for nearly 2hrs.
I finally pulled the radio stick, rebooted, restored, shutdown, put the stick back in, rebooted again. Everything is still super slow so I guess I'll have to restore to an older backup.
What the hell goes on in there? It's getting pretty tiresome to break the hub EVERY SINGLE DAY for a month. Time to start looking at HomeSeer or OpenHAB.
I have found HE to be fragile. I know it's young, but at this point it is more fragile than ST. It seems:
when developing code, it is easy to have errors, that result in "compute bound loops". Bad arguments, etc.
-- only way to fix is to reboot and catch/delete the offending app quickly
-- there should be some termination / resource limiter to stop this before everything grinds to a halt
it seems under memory-ied or storage-ed. Running large smart apps seem to run it out of resources (just in size when compiling).
The use of RM will never work for novices. Too much "in your head" factoring of a problem into a bunch of rules that interact. Having 100s of rules is impossible for anyone to understand, especially novices. This is where webcore is better. However the above two items hurt webcore (and any other large app)
The black box nature says a lot of trial and error to figure out what is wrong, especially when you get bit by #1, or #2.
The lack of access to the built in device handler code is a poor idea. HE got to build the system off other's work, yet refuses to let others customize off their device work. I just don't get it - using open source but not sharing back at all is just bad form. I don't see the business logic this.
So my suggestions:
put a rate limiter / execution timeout / fair share scheduler (or have settings that by default they are on).
give the system more memory / storage (and if needed more CPU). Why should you care if my automations are large, slow, etc? They are mine!
give folks insight into how the system is doing, what is running a lot. Can't optimize what you can't see.
put the sources out for your device handlers. It will improve a lot of things.
add support for webcore. This RM vs. webcore argument is a waste of time. RM is not going to expand the market for you much as "grandma" is never going to grok it. She may not grok webcore either, but folks can share apps in webcore so she does not have to.
Another wild suggestion:
sell the HE environment as a software product - ie a container for Linux. Decide it works with pi or ubuntu or whatever, and folks buy the radio stick and the software, and run it where they want. They can give it the resources it needs.
I feel like I was so close to having the damn thing running stably. I had 1 more bug to fix but in the process of doing that, I discovered another thing ( my missing lock) that I fixed 2 weeks ago, and then everything fell apart.... AGAIN.
Then you realize the truth of the situation, which is that I've felt like that EVERY SINGLE DAY FOR FOUR WEEEKS!
At some point you have to give up on the CPR and call it.
Just remember, every one here is an early adopter. Better things will come but I think you can't compare ST box with HE box, come on ST processing power comes from a server, HE has a small CPU that Webcore needs almost completely. Yes, I had to uninstall Webcore from my life, honestly, I don't need it anymore.
Interesting perspective. Not one that we agree with, but interesting.
Every app and driver for the system has been developed on the platform itself, and we have not had the experience of "compute bound loops", etc., although there are plenty of errors as development progresses. We have not had this experience of coding practices leading to apps or drivers that crash the hub that you describe as a concern.
As to memory and storage, my home hub is where I do most development work, and I've never had storage or memory issues with it (same hub that you have). Many thousands of lines of code, many dozens of apps and drivers code, and my house is running on it at the same time, 260 devices, 120 installed apps. It's rare to have an issue with the hub, as my wife would kill me if the house went back to being flaky.
The "black box" nature of the hub has nothing to do with figuring out what is or is not working. Diving down into the OS is not going to shed any useful light on a misbehaving app. There is nothing under the covers that would be of use to a developer on this platform, speaking from a lot of experience. It's very straight forward to put debug code in apps and drivers. As I mentioned, we do all of the app and driver development in this very environment and basically never touch the OS, never have reason to look at TOP or any other OS utility. You aren't missing out on any information that is needed for swift development and debugging.
All of the built-in apps and drivers were implemented from scratch, not from open-source code. The hub itself was constructed also from scratch. We have no obligation or reason to share our proprietary code base with others.
Not sure why it comes as a surprise that a large and complex app designed and developed to run in the ST cloud would have issues in a different environment. WebCoRE does all sorts of things that only make sense in the ST cloud, not in this environment. We aren't likely to ever support webCoRE as it exists at present, although we may very well bring out something with a similar front-end for authoring automations.
Well first off, I'm back up and everything is lickety-split again. For now. The usual procedure. Restore from a good backup, boot without the stick, pause all webcore pistons. Boot with the stick, restore pistons. This takes 90m every day or two, which is getting awfully tiresome. Damn even my back lock works again, though it takes about 10sec to do anything.
Whats so heartbreaking about WebCoRE is that it works pretty well 95% of the time but then somehow falls down the stairs and takes the whole hub with it. Whatever happens, this broken-ness appears to be durable across reboots, so something seems to be getting pretty seriously corrupted. I would think that alone would trouble you guys enough to have a look. If webcore can break things this badly, can't any user app?
From a business perspective, it seems to me that having WebCoRE on the platform is a feather in your cap, and one that you guys got almost completely for free. Even if you plan on replacing it later, throwing a day or two at stabilizing it seems like a win, just to get over the hump.
Yes please to a webcore replacement! I'm not in love with WebCoRE so much as the ability to visualize the logic of my script. For god's sake though, if you're going to make something like it, just give us a text box where we can paste or upload text! I'm pretty over the pointing and clicking.
Sorry to jump in but I've been having issue rebooting as well so here are my thoughts. You guys keep blaming third party app so have a way to boot the hub that won't auto start third party apps then (ala SAFE MODE). Every time I reboot lately, I'm rolling the dice with the HUB rebooting OK. It seems I have to reboot multiple times lately to get a fast responding HUB.
Sorry, that's not on our list. It's just not reasonable for you to expect this to be an environment that is resilient against buggy code that crashes the hub. Writing code for this environment that does not crash the hub is not difficult at all. We know, we've been doing it for a long time. The more you guys complain about how your code doesn't work, the less sympathy you're going to get.
Iām a novice. I have NO idea what Iām doing. I purchased the hub knowing Iām an early adopter. Yet, I created two rules all by myself via RM. I have some minor quirks that I will note at a later time.
Iām confident this product will get better over time.
