Hubitat Elevation

#169

Global variables not only carry info from one piston to another, but they are used in multiple pistons. Why define the same thing many times if you only need define it once, and then let many pistons utilize it? My window groupings are like that, used in multiple pistons. I also have a Holiday variable that gets set based on the actions of one piston and used as a reference for action in two others… but by itself does not trigger anything. Presumably, that should also then be clear.

Additionally I have a Boolean week alternator variable (because the Webcore “once every two weeks” function does not work well) that gets set by one piston and called by another. But it is not a trigger. The day of the week is the trigger, and the piston only does its thing if the week alternator variable is true.

It would never have occurred to me to have the mere existence of a global variable be a trigger for actions. That’s not good programming practice… in fact, now that I have examined all my pistons I see that anything I have that defines a global variable is in its own piston, a piston designed specifically to set that variable. I’ve not even been consciously aware that’s what I was doing! Guess it’s a carryover from my days of actual programming (two decades ago lol)

#170

Well that’s it for me an hubitat. I’m going to migrate back to ST this weekend… or… f*ck I don’t know at this point… maybe HA. I just need to get something half-assed together stably so the house works until I can make the next move. This has been an absolute disaster.

The reality of ST vs Hubitat is that ST is the more open platform of the two.

While local processing sounds good, it’s pretty damn easy to brick the hub. The hubitat crew blames WebCoRE for this, and that’s probably true but you don’t really know do you? It’s a black box. There’s no process management, or stats on memory or cpu usage and it doesn’t sound like there ever will be. Sometimes its fast, sometimes its slow and you have no idea why. Bring it up with Hubitat and they tell you to “take responsibility for your code”.

It seems to get pretty un-recoverably f8cked on nearly a daily basis and they provide no tools for de-buging or recovery short of fully restoring a backup, and now I can’t even do that. At the moment the hub is bricked. Bricked across reboots. Bricked in such a way that I can’t even restore a backup. It comes up, but just spins. This probably is webCoRE, but there’s no way to stop it.

Just use RM is their answer to everything, and even if I could get the box back alive to restore, that answer doesn’t work for me. I need to be able to read my code, back up my code, and copy my code. I need to be able to script the house with logic I want, not that some App writer decided is best. The whole “App” model was always crap.

I had a lot of time invested in making things the way I want with webcore, and while it seemed that hubitat offered an upgrade path for that, it doesn’t. The official guys have no desire to support webcore, and whatever community group that was working on it, that project seems dead. I don’t blame them. It’s pretty difficult to debug something on a platform that gives you no insight at all. The hubitat guys seem to want to dig their heels in about this, getting all, “we have the right to protect our IP, yada yada yada”. That’s great, but we users also have a right to flee your east german black box prison.

What a nightmare. Literally 4 hours a day for a month and nothing to show for it, now I’m looking at either spending the whole weekend migrating back to ST or… ?? HA? I mean hell if I’m going to d*ck around on a broken platform, I want it at least to be open. It’s really a shame. So promising, and so close to working.

#171

I would say yes. The reason being that I was getting issues around once a week with things slowing down making things unusable. A reboot would cure things for a week. I paused all my pistons and disabled webCoRE in the app and my problems stopped. Just my observations.
I know this doesn’t help you if you cannot get into the UI to do things.

#172

I have zero doubt that webcore is the trigger here, but the problems seem deeper than that in the way the whole damn hub locks up and stays locked up across reboots, even when all pistons are disabled.

#173

I’m sitting here looking at a Please Wait, Restoring Backup. Screen for the last 45 minutes. How is that webcore’s fault?

The stick is pulled out so there should be no events coming in. Webcore is in its “disable all pistons state”…

#174

What do your piston subscriptions look like? Do you have a lot of time based ones (every minute, every 10 seconds…) or others that can happen on boot? Even if you disable the pistons the child webcore piston app has to compile in response to events or app calls, which in my testing can be problematic since there isn’t something in place to prevent multiple pistons and the parent from compiling at once at bootup. This might be a problem for a large app which takes awhile to compile anyway combined with bootup (but again this is speculation from testing I’ve done since I haven’t had this problem of lockups. I have around 50-60 pistons) It could also be one bad piston dragging down the rest of the hub.

We’re you only having issues on boot or was it slow during normal operation? Can you share logs of the hub starting up?

#175

Have you researched any “other” systems. I jumped to HE also but mostly becaues of the thought of webcore working. Now that we know it “kind of” works… does anyone have experience with Homeseer or other platforms? I’m not really worried about saving a few dollars as I know those other platforms are more expensive. I want something that gave me the flexibility that webcore did…local processing would be nice…

#176

Well, I can’t get anything out of the hub at the moment. I can’t even restore it. The restore upload is crawling and doesn’t look like it will finish.

As for normal operation, mostly it was pretty snappy but then it would slow precipitously and stay that way. I don’t have a lot of time based pistons. I have a few with some somewhat complex subscriptions, but they mostly worked. Things seemed to me to break when editing pistons, so I suspected whatever webcore storage was doing…

#177

WebCoRE most assuredly does not work. It’s in the most torturous possible state of almost working, and HE has no intent to address it.

I would advise you to stay well away unless you want to end up like me, sitting here in my sad, dark, broken house :wink:

I also can’t emphasize enough how much of a black box this platform is. You’re trading in your Samsung cloud dependencies, for HE “trust us its working, cuz we say so, the problem is you” black box dependencies.

Just bought an Rpi 3. I’m going to Home Assistant. The HUSBZB-1 that comes with HE might even be compatible, just peel off the sticker!

#178

I’m telling you, from all the logs I’ve seen, global variables are a big cause. I had one global variable update in one piston and all of a sudden I had 35 piston executions of various pistons. I removed the global variables and I now get one execution as I’m supposed to.

#179

Can’t even get the box back alive dude…

#180

My HE hub is probably twiddling its electronic thumbs right now, all I have are water sensors :slight_smile: I haven’t gotten to the the unpairing from ST and moving to HE… I might need a week off work. I don’t have a lot of devices, just dreading the actual act lol :smiley:

#181

It was EXTREMELY painful at first. But now I think I’m in a good place. I still have webCoRE installed, much to many people’s dismay and amazement on the Hubitat forum. But I have it limited to those things that HE can’t do at all yet…parsing data from HTTP calls; variables; using other device attributes as triggers. I’m down to about 10 pistons but they are integral to my system. So, I’m glad webCoRE is still an option on HE and hasn’t been removed…yet. And I can understand support not wanting to spend time helping debug custom code. It’s not like we pay a monthly subscription fee. They’ve gotten my $100. That’s all they’re gonna get from me. So, I shouldn’t expect them to help me with something that I brought to the hub. That’s my responsibility. The system is what it is and you have to either take it or leave it.

#182

I only have the Nest Protects left on ST at this location … however, I have 110+ devices at the other place to do, LOL … but, I have a plan :smile:

“Everyone has a plan, until they get punched in the mouth.”
— Mike Tyson —

#183

I like that… a plan lol. I installed the Other Hub app in HE thinking I’m being smart and removed one of my peanut plugs from ST, moved it to HE thinking I can use it to repeat for me Xiaomi water sensors. Buuuut NOOOO… I found out later, the peanut plug is on the Xiaomi naughty list. :angry:

I have RM app installed but every time I look at some of the RM snapshots my eyes glaze over… one of these days I will have to re-learn how to use it. Heck I even have the old version installed in IDE still.

#184

Yeah, did the same, but looking back, I think it took me longer to migrate everything over doing it that way (one device at a time, using Hub Link, Other Hub, etc. … making sure everything still worked on the ST side.)

My plan is to go all out, LOL … unpair EVERYTHING from ST with my Minimote, then pair the lines devices (wall switches, power outlets) on Habitat … do several Z-Wave mesh repairs … then pair the door locks and contact sensors … next pair the pocket sockets. From there I can create the new pistons (important ones first; I already installed WC, the needed driver and app codes on the new Habitat hub) from the backup PINs on the ST webCoRE. Only thing left is to reassign the devices to the Hubitat pistons, using the ST ones as reference.

Hope that works, LOL … too bad about the Peanut plug.

#185

Wait until 4 weeks after you’ve done all that and you’re facing the prospects of moving back… all after spending hours a day every day trying to get the damn thing stable. Be very very afraid.

#186

I think their is a fundamental issue that “runaway” apps (regardless of webcore or groovy), can make the HE unusable.

Their response is bad user / bad app. OK, but the platform should have some watchdog/catchall to stop this (ST does this with execution timeouts, there are many other ways).

It happens that webcore can be easy to create one of these loops (just as when writing groovy code).

My view is they are having an over-reaction. They really want folks to go back to rule machine - I just can’t do that given it was taken away from me once already.

They could have made the statement more general - we don’t support apps you wrote (that have problems).

The core issue is a bad app can take down the hub, so the simple response is don’t do that. But you cannot write new apps (in groovy, or webcore) without likely making mistakes.

The actual problem is webcore is easy enough for many folks to write apps (and have bugs in them) that HE cannot protect itself from.

I love startups that are so passionate as to call their users “bad”…do 2-3 startups and you will realize this is the kiss of death.

#187

“I love startups that are so passionate as to call their users “bad”…do 2-3 startups and you will realize this is the kiss of death.”

Yeah that’s the smell I got yesterday afternoon and it was, for me, the final straw. I’m not looking forward to a dark house over the holidays but I’ll take it over working with a vendor with that attitude. I mean, that’s how Jeff Bezos got where he is today right? Telling people that wrong book was really what they ordered and they should just learn to like it.

My other issue is that give me ps, df, and a kill command and I could probably get webcore limping along acceptably enough to keep me happy for quite a while, but they won’t do it because they want to keep their IP hidden or something. What does a “developer community” built around those values look like in a year? A ghost town IMHO.

That and frankly I’m still baffled exactly how WebCoRE, with no radio installed (and no events) is preventing HE from restoring from a backup. I’ve tried about 10x times now. The hub locks up in an unrecoverable state immediately after boot. How is that ever acceptable?

#188

Whatever, yeah i’m just kind of pissed and venting because I wasted a lot of effort and now my house is dead and I have no real idea of what I’m going to do going forward. No options look that good at this point. Either re-pair 130+ devices to ST, or see if I can move the hubitat stick to Home Assistant on an rPI3… and hope enough of my devices are supported that I can limp along while I re-write the handler for my thermostat. At least HA is transparent.

I need get AFK for a while and chill out…