Hubitat Elevation

#163

I’m considering moving to Hubitat. Mainly because I finally have a functioning PC in the house again lol

But I’ve now got so many of my automations running on Webcore that I’m somewhat attached to it. And seeing the issues in this thread and other areas has me a bit leery.

It all kinda shows why the original Smartthings team sold out to Samsung. I’d hate to make a move of this magnitude, only to find myself either hung out to dry or bound yet again to a large company with crappy customer service. Then again, at some point in the next many months or so Samsung will force us all into the new smartthings, at which point it’s clear that many of my most useful automations (such as presence unlocking my smart lock) will be destroyed anyway.

Tough decisions ahead.

#164

Well, I’m already in that hung out to dry position so I suppose I’m going to go ahead and try to patch WebCoRE on hubitat myself, just enough to be able to disable pistons on reboot. This ought to enable a bit faster recovery when things do go south.

@Ryan780 I’ve been watching the logs and see what you mean about globals…

#165

They are bad news! Ever since I got rid of all of them, running like a top. I’ve been telling anyone who’ll listen, if you get rid of globals, you will eliminate your lock up.
There already is a setting to disable all pistons in settings btw.
And the reason people are having trouble at boot is because a whole mess of global variables are being updated. And every time one is, every piston is evaluated. Do the math on that one. It HELLA HUGE! But unfortunately, it doesn’t seem like anyone was listening, before you. :grin:

#166

That disable all setting isn’t the same… it looks like they’re all still processing events, just no actions. I want to pause all pistons on startup.

#167

Ok, so I’m not yet in Hubitat. But I want to understand this firmly as part of my decision process in whether to make the move.

I have a global variable called “ALL WINDOWS”. I use it to report on whether any windows are open.
But I don’t use the variable as the trigger. My piston says “if garage and front door have both been opened within the past minute, then it looks like you might be leaving the house - so I’m checking to see which windows are open. Here they are:” and it proceeds to tell me which ones remain open.

So hypothetically, including a new window in that variable should affect nothing. Because WC has no reason to check/update it unless the piston is executing.

What am I missing?

#168

Why would you have that as a global variable in the first place? If it’s not used by another piston, there’s no reason it shouldn’t be a local variable to that piston.
But yes, if you aren’t using a global variable as a condition or a restriction or a trigger, then no, you wouldn’t run into this problem.
However, typically global variable are used to carry info from one piston to another so that some other action can be taken.
However, let’s say that you had some other global variable defined as a trigger for a different piston. If you change this variable, that other piston would be reevaluated when you set this variable. Every time you set this variable. Trust me, I’ve seen the logs. I had 35 piston executions when it should have been one. But don’t take my word for it.
But I do advise you to read all the posts on webCoRE on the Hubitat forum.

#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 —